HANA

SAP Central Finance: a non-disruptive step towards system consolidation

Operating across a distributed environment has become a way of life for a large percentage of businesses today, even smaller ones. In fact 80% of all survey participants in the 2015 Mint Jutras Enterprise Solution Study had more than one operating location served by ERP (Figure 1). Even small companies (those with annual revenues lower than $25 million) average 2.87 operating locations, and that number grows steadily as revenues grow.

Figure 1: Environments Are More Distributed and Remote

Fig 1 SAPSource: Mint Jutras 2015 Enterprise Solution Study

This proliferation of operating locations often results in a proliferation of enterprise applications in general and ERP solutions in particular. In days gone by, these different operating sites were often left on their own to select the enterprise applications that would help them run their individual businesses. Yes there was a corporate accounting system, and financials needed to be rolled up. But those corporate financials were overkill at the divisional level, and often didn’t have all the functionality needed to manage operations, particularly in manufacturing sites.

As long as these different operating sites operated quite independently, this proliferation wasn’t too much of a problem. But today the likelihood of divisions operating completely autonomously has dramatically shrunk. Whether you are a services organization working on projects that span the globe or a manufacturer striving to manufacture closer to your customer, leaving each operating location to do their own thing just doesn’t cut it anymore. Standardized processes and corporate standards for the enterprise applications that support those processes have become the norm.

The majority (87%) of multi-location companies today have created standards that govern which enterprise applications are used across the enterprise (Figure 2). However, a fair number (14%) are still in the process of migrating to these standards, which means they are faced with the challenge of rationalizing existing solutions that are functioning today. Typically this means a long process of ripping and replacing solutions and many years before they see the benefits.

Figure 2: Have you established corporate standards for enterprise applications?

Fig 2 SAPSource: Mint Jutras 2015 Enterprise Solution Study

For SAP customers, SAP Central Finance might just be a shortcut to some of those benefits. It provides more than just the typical kind of consolidated reporting that is done at the aggregate level. Central Finance taps into the power of SAP HANA and replicates all journal entries in a Universal Ledger, while preserving the source of those entries, whether the source is an SAP ERP solution or not. Of course it takes a bit more effort to map the data from nonSAP solutions, but SAP has tools to help and it is quite do-able.

What this accomplishes immediately: Centralized reporting across the organization, beyond the typical financial reporting, and also the potential for more informed centralized strategic decision-making.

  • Reporting based on harmonized master data
  • Central journal for balance sheet and P&L reports
  • Central profitability analysis
  • Overarching views on customer and vendor accounts
  • Liquidity forecasts based on payables and receivables
  • Central overhead analysis
  • Reports for selected cost object categories

… All this without ripping or replacing anything. Of course, some might stop here, centralizing finance and leaving disparate ERP solutions in place, while others might move on to rationalize solutions. … or some combination of the two. Mint Jutras finds there are several different flavors of corporate standards (Figure 3).

Figure 3: Is this a single or multi-tier standard?

Fig 3 SAPSource: Mint Jutras 2015 Enterprise Solution Study

Although those all running a single ERP solution won’t need to rationalize solutions, they are still likely to need to consolidate financials, especially those that are multi-national. Central Finance could also be used to absorb a new acquisition, incorporating the new entity into corporate financials. Today Central Finance can be used for corporate reporting and planning, but as SAP continues executing on its planned roadmap, in the future, customers will be able to use it for central operational processing

To sum up both approaches….

Central Finance as a corporate reporting and planning platform:

  • Establishes central financial system as a single source of truth
  • Across entities and units
  • With harmonized master data
  • Using the flexible data model of Simple Finance (now called SAP S/4HANA Finance), with the possibility of adding new dimensions for reporting that might not even be available in source systems
  • With new reporting tools
  • And the speed of HAHA
  • Cross-entity insight with limitless detail. You can even click on a document ID in Central Finance to navigate back to the source system (think traceability). This is done automatically when the source system is an SAP product. Doing the same for nonSAP systems requires additional effort.

Central Finance for operational processing

  • Simplify and standardize processes
  • By centralizing financial processes
  • By standardizing, harmonizing processes across units
  • Move processes to central execution models while streamlining processes based on harmonized data
  • Possibly simplify work in shared service centers
  • Simplify your IT landscape

Whether you need to consolidate financials only, or entire ERP systems, if you are an SAP customer, you owe it to yourself to investigate how Central Finance could make your life easier.

Tagged , , , , , , , , ,

SAP Leverages the “Power of Big” to Benefit SMEs

Some common myths and misconceptions in the world of ERP are hard to kill, particularly when competitors and pundits just won’t let them die. Among these common myths is the perception that SAP is just for the big guys. Yes, the SAP Business Suite and even some predecessors to the Suite are installed in a large percentage of the Fortune 500. And yes, some of them cost millions of dollars and took many years to implement. Of course there are some horror stories, but I would argue those exist for any major ERP vendor.

I have to admit, during my 30+ years of working for software companies (but never for SAP), I might have encouraged some of those misconceptions, just as SAP’s competitors do today. But now, as a recovering software executive turned data junkie, I tend to look beyond the rumors and misperceptions. I go for the facts. Here are a few that are hard to argue with:

  • SAP has about 263,000 customers
  • 80% of them fall in the small to mid-size (SME) bracket. Do the math. The answer is 210,400.
  • SAP does not sell just one product. There is the Business Suite, but also SAP Business One and SAP Business ByDesign (no it is not dead or dying). SAP Business All-in-One is the Business Suite repackaged, by industry, for medium size businesses. You might choose to call it a different product or not, but it really matters little. Repackaged with best practices included, it makes the Business Suite more attractive to smaller (but not too small) companies.
  • SAP Business One, which addresses the lower end of the SME market, is installed in over 45,000 small businesses.
  • SAP’s ecosystem of partners that support small to mid-size businesses is 700 strong and growing.

I am sure one of SAP’s goals for this year’s annual SAP SME Summit was (once again) to help dispel these myths and misconceptions. I am equally sure that SAP understands it will take more than just bringing together customers, press and analysts in its hip New York City office to counter these perceptions. Instead, it seems to be effectively leveraging its extensive resources in order to help small and medium size businesses. Here are a few of different actions it has taken recently:

  • SAP HANA 9 can now be run on less expensive hardware
  • Powerful data visualization tools are available with a copy of SAP Lumira, free to any SAP customer
  • Fiori apps, providing an intuitive and modern new user experience, are now included for free (with paid maintenance) with SAP Business All-in-One
  • A 0% financing program, designed specifically for small businesses, as well as SAP’s partners that sell directly to them. This is a “buy now, pay later” option that gives the small business free financing for 24 months, while the partner gets paid within 5 days.
  • A free connection to the Ariba Network, which connects over 1.6 million companies in 190 countries, allows the small business to list its products. Although the free version does not allow bidding and purchase from the site, this is an effective way for small businesses to reach a large potential group of buyers.

It takes a large company with deep pockets and extensive resources to be able to make these kinds of offers to SMEs. Yes SAP continues to be the 800-pound gorilla in the ERP space but that doesn’t mean it can leverage the “power of big” to the benefit of the little guy.

Tagged , , , , , , , , , ,

Can Running SAP Business Suite on SAP HANA Be a Game Changer?

It can if you change the conversation

Back in February I posted this update on SAP Business Suite on HANA after having spoken with Jeff Woods, former industry analyst, currently Suite on HANA aficionado at SAP.

As a follow-up I joined Katie Moser for a webcast.

Click here to listen to the webcast

And now for the original post:

Jeff had lots of good stuff to share, including some progress to date:

  • 800+ Suite on HANA contracts have been signed
  • 7,600+ partners have been trained
  • There are 200+ Suite on HANA projects underway
  • 55 of these projects have gone live (and the number is growing)
  • The largest ERP on HANA system supports 100,000 users

So the Suite on HANA is quite real. But the single message that resonated the most strongly with me: the conversation has (finally) changed. While we’ve been hearing about HANA as this wonderful new technology for several years now, for the most part, the talk was about technology and even when the technologists spoke about purported business value, they spoke in very technical terms. But the audience I write for, business leaders in various industries, don’t care about technology for technology sake. Many don’t (care to) understand tech-speak. But they do care about what technology can do for them.

A Year Later…

It was just about a year ago that SAP announced the availability of SAP Business Suite powered by HANA, complete with live and live-streamed press conferences in both New York City and Waldorf, Germany. I don’t think I have ever seen such genuine excitement from SAP folks as was displayed in this announcement, and yet the “influencers” in the audience were a bit more subdued. A year ago I attributed this to the fact that these same influencers tend to be a quite jaded bunch, hard to impress. We had also been hearing about HANA for a few years already. There wasn’t a “newness” or game-changing feel about the announcement. But impressing the influencers is only one step towards the real goal of engaging with prospects and customers.

A year ago I also wrote, “SAP is trying hard to change the conversation to be less about the technology and more about the business value.  What is the real value? In the words of one early adopter: HANA solves problems that were deemed unsolvable in the past.” But uncovering those previously unsolvable problems required some visionary thinking.  Tech-speak is not going to get the attention of the guy (or gal) that signs the check or spur that kind of thinking. And a year ago the conversation hadn’t changed. Just look at how the vision of HANA was portrayed:

  • All active data must be in memory, ridding the world of the “rusty spinning disk”
  • Full exploitation of massively parallel processing (MPP) in order to efficiently support more users
  • The same database used for online transaction processing (OLTP) and analytics, eliminating the need for a data warehouse as a reporting tool for OLTP to support live conversations rather than “prefabricated briefing books”
  • Radically simplified data models
  • Aggressive use of math
  • Use of design thinking throughout the model

Look carefully at those words. They mean nothing to the non-technical business executive. Sure, those words got the attention of some forward thinking CIO’s, and that was enough to kick start the early projects, projects that produced amazing results. But that’s as far as the message got. And even when the message was not articulated in technical terms, it was presented at too high a level of abstraction. Business executives faced with important decisions don’t think in terms of “becoming a real-time business.” Operational managers don’t seek out “transformative innovation without disruption.” They want to get through the day most effectively and efficiently and make the right decisions.

Asking the Right Questions Today

So how do you change the conversation? By asking a different kind of question. Because “faster” is universally accepted as a good thing, in the beginning the HANA conversation might have been kicked off with the question to the CIO: What processes are running too slowly today? But in talking to the business user, you need a different approach. SAP’s “cue card” below is a good start. You are now seeing conversation starters that make more sense to the business leader. Take the time now to read them carefully. If you are a business leader, they will resonate much more than discussions of MPP and column-oriented databases or even speed of processes. I especially like the business practice questions in the rightmost column.

Cue card

Source: SAP

But if I were sitting across the table from a business leader, I might ask questions that are even more direct and down-to-earth. For example:

  • Describe a situation where you have to hang up the phone, dig deeper and get back to your customer or prospect later. (By the way Jeff’s thought was that by hanging up you only encourage them to pick up the phone and call your competitor.)
  • What summary data do you get today that consistently requires more detail before you make a decision? Can you get at that data immediately (no delays) and easily (no hunting around)?
  • What level of granularity are you forecasting revenue? Is it sufficiently detailed? Are you forecasting by region or maybe by product line when you would love to be able to forecast by territory, individual customer and individual product combined?
  • Are there decisions that require you to consult with others? How much time does this add to the decision-making process? How easy or hard is it to keep track of who to contact? How quickly can you make contact? Quickly enough?

The goal really is to improve the business not only in small linear steps, but also to increase speed of decision and therefore efficiency exponentially. The first step is to provide new ways of engaging with the system, which means changing the user experience. But to change the game, you need to make improvements to the process itself. SAP’s new Fiori applications are a good example of this progression.

 Fiori: More Than Just a Pretty Face

Last spring, SAP announced SAP Fiori, a collection of 25 apps that would surround the Business Suite, providing a new user experience for the most commonly used business functions of ERP. While useful in pleasing existing users and perhaps even attracting new users within the enterprise, this first set of apps just changed the user interface and did not add any significant new functionality.

The latest installment has 190+ apps supporting a variety of roles in lines of business including human resources (HR), finance, manufacturing, procurement and sales, providing enhanced user productivity and personalization capabilities. The apps offer users the ability to conduct transactions, get insight and take action, and view “factsheets” and contextual information. The next round of Fiori apps are expected to add even more new capabilities, thereby taking them to the next level in changing the game.

The MRP cockpit is an example of this next generation Fiori app and a perfect illustration of how these new apps can recreate processes, even ones that are 30 years old. If you “know” manufacturing, you probably also know that the introduction of Material Requirements Planning (MRP) software back in the late 70’s was transformational, although nobody really called it that back then. “Transformative” innovation is very much a 21st century term. But it truly was game-changing back in the day.

Last year, even before the conversation had shifted, I saw the parallels between the potential for HANA and the automation of the planning process that MRP brought about. Today the MRP cockpit delivers on that potential.

For those outside the world of manufacturing, in a nutshell, MRP takes a combination of actual and forecasted demand and cascades it through bills of material, netting exploded demand against existing inventory and planned receipts. The result is a plan that includes the release of purchase orders and shop orders and reschedule messages. While the concept might be simple enough, these bills of material could be many layers deep and encompass hundreds or even thousands of component parts and subassemblies. Forecasts are educated guesses and actual demand can fluctuate from day to day. Without automated MRP there is simply too much data and complexity for a human to possibly work with.

As a result, prior to MRP, other ways of managing inventory became commonplace. You had simple reorder points. Once inventory got below a certain point, you bought some more, whether you actually needed it or not. You also had safety stock as a buffer, and the “two bin” system was quite prevalent. When one bin was empty, you switched to the other and ordered more. These simplistic methods may have been effective in some environments, but the net result was the risk of inflated inventory while still experiencing stock outs. You had lots of inventory, just not what the customer wanted, when it wanted it. And planners and schedulers still had to figure out when to start production and they knew enough to build a lot of slack time into the schedule. So lead times also became inflated and customer request dates were in jeopardy.

Once MRP entered the picture, these were seen as archaic and imprecise planning methods. Even so, most didn’t rush right out and invest in MRP when it was first introduced. In fact now, decades later, the adoption rates of MRP in manufacturing still sits at about 78%. Why? The existing practices were deemed “good enough” and, after all, that’s the way it had always been done.

It required a paradigm shift to understand the potential of MRP and the planning process executed by MRP was complex. Not everyone intuitively understood it. And if they didn’t really understand, planners were unwilling to relinquish control. Particularly since MRP runs were notoriously slow.

It was not unusual for early MRP runs to take a full weekend to process, and during that time nobody could be touching the data. This didn’t work so well in 24X7 operations or where operations spanned multiple time zones. Of course over time, this was enhanced so that most MRPs today run faster and can operate on replicated data, so that operations can continue. But that only means it might be out of date even before it completes. And MRP never creates a perfect plan. It assumes infinite capacity and “trusts” production run times and supplier lead times implicitly. So while most planners were relieved of the burden of crunching the numbers, they were also burdened with lots of exceptions and expedited orders.

Yet over time, MRP brought a new dimension to material planning. It brought a level of accuracy previously unheard of and helped get inventory and lead times in check. Manufacturers have experienced an average of 10% to 20% reduction in inventory and similar improvements in complete and on-time delivery as a result of implementing MRP.

But through the past three decades, MRP hasn’t changed all that much. Yes it has improved and gotten faster, but it hasn’t changed the game because it still involves batch runs, replicated data and manual intervention to resolve those exceptions and expedite orders. Now with HANA we’re not talking about speeding up the processes by 10% to 20% but by several orders of magnitude, allowing them to run in real time, as often as necessary. But if it was just about speed, we might have seen this problem solved years ago.

You probably don’t remember Carp Systems International or Monenco, both Canadian firms that offered “fast MRP”. Carp was founded in 1984, and released a product in 1990 bringing MRP processing times from tens of hours down to 10 minutes. It ran on IBM’s RS6000 (a family of RISC-based UNIX servers, workstations and supercomputers). But it was both complex and expensive for its time ranging in price from $150,000 to $1 million). Not only was it expensive and required special servers, in order it to work it needed to replicate the data and then apply sophisticated algorithms.

About the same time Monenco introduced FastMRP, also a simulation tool, but one that ran on a personal computer. While it cost much less than Carp’s product, it was also less powerful and had significantly fewer features.

You won’t find either of these products on the market today. If speed was all that was required they would have survived and thrived. In order to change the game, you also need to change the process, which is exactly what SAP intends with its new Fiori app for MRP.

The new MRP cockpit includes new capabilities, like the ability to:

  • View inventory position looking across multiple plants
  • Analyze component requirements with real-time analytics
  • Perform long term MRP simulations
  • Analyze capacity requirements and suggest alternatives

But this too requires a paradigm shift. Manufacturers, as well as other types of companies, are quite accustomed to making decisions from a snapshot of data, usually in report format, possibly through spreadsheets. They have become desensitized to the fact that this snapshot is just that, a picture of the data, frozen in time.

What if you never had to run another report? Instead, whenever you needed a piece of data or an answer to a question, you had immediate and direct access, not to the data as it was at the beginning of the day, or the end of last week, but to the latest data in real time? Not only will decision-makers need to adjust to thinking in real-time, but will also have to trust the software to automate much of the thinking for them. Will they be able to sit back and let the software iterate through multiple simulations in order to find the best answer to an exception even before it is reported as an exception? I suspect they will if it is fast enough. And HANA is now delivering at speeds that just a few years ago would have been impossible. But with these speeds accelerating by orders of magnitude, the ability to communicate and collaborate effectively must also accelerate.

Making the Human Connection

It is not enough to change the way users engage with the software, it is also necessary to change the way they engage with other people. How often do you or your employees today express sentiments like:

  • If I just knew who to contact for approval/help….
  • I don’t know what to ask
  • I wish I could check with (several) people on this quickly

What if the software could help? As work flows are streamlined, automated and accelerated, so must the lines of communication and potential collaboration. Whether employees are looking to move a process forward, resolve an issue or mature an idea faster, lack of communication and clumsy modes of collaboration can inhibit the game-changing effect of the technology. Which is why SAP has upped its game in the area of Human Capital Management and social collaboration tools. It took a significant step forward with the acquisition of SuccessFactors and JAM and has been blending these capabilities with the HANA platform.

Key Takeaways

Nobody today would disagree that the SAP Business Suite, powered by HANA combines deep and rich functionality with powerful technology. But can it be game changing in terms of how businesses operate? The potential certainly exists, but it’s not just about speed. Changing the game means changing the way we’ve been doing things for decades. Before we can change the process, we need to change the conversation. Are you looking to optimize business processes? Are you ready to talk?

Tagged , , , , , , , , , ,

The Message from SapphireNow was Simple

Period.

You probably thought I was going to tell you what the message was, after describing it as simple, right? Wrong. “Simple” is the message. In the past, SAP’s products and SAP, the company has been anything but simple. Anyone that follows me knows I am a very big fan of keeping things simple. I spend a good chunk of my time and efforts distilling complex concepts down to understandable …simple terms. So you might think I would be thrilled with this message. But when I walked out of Bill McDermott’s keynote earlier this week, there was something about the message I found troubling. My issue: Business isn’t simple.

No place is this more apparent than in manufacturing, which is sort of “home” for me. But all enterprises face complexities. First of all, all are becoming more distributed. My research shows even the average small company (with annual revenues under $25 million) has 2.2 operating locations. That number escalates to 13.7 in large enterprises (over $1 billion in annual revenues). Increasingly these are global organizations, managing complex, global supply chains. Add to this changing regulatory requirements, the uncertainties of a global economy and the emergence of new sources of competition as well as new markets. There is no magic wand anyone is going to wave that will remove these complexities. And yet with the liberal use of quotable sound bites generated on the main stage, I had visions of SAP’s personnel aggressively promoting and promising “simple business.”

Then I happened to have a conversation with Josh Greenbaum (@josheac) about our mutual reactions to Bill McDermott’s keynote. A remark from Josh made it all click for me. Essentially what he said was: “Simple” is the wrong word. “Simplify” says it much better. Josh is right.

Yes, doing business with SAP could be simplified, both from a partner and a customer perspective, as well as from a supplier standpoint (I can personally attest to the latter – yes, SAP is my customer). The software products and associated implementations scream for simplification. The way innovation is delivered can be made simpler. So can pricing. The same can be said for SAP’s organizational structure. So the real question is: Can SAP deliver on this promise to simplify? There is no single answer. Instead you need to break it down by the many different opportunities for simplification. Here are a few.

SAP’s Organizational Structure

We’ve already seen a few changes here. Obviously with Jim Hagemann Snabe stepping out of the co-CEO role, leaving Bill McDermott as the sole CEO, this, in of itself, could be seen as a simplification. And I think this was a catalyst for creating the focus on “simple.” I am convinced that this is not just a word, a tagline or a marketing message to Bill. He is truly committed to simplifying everything he can. Indeed SAP has already made some organizational moves, but I would say the jury is still out on whether SAP can really deliver on this one.

I gave up a long time ago trying to figure out the organizational structure and who does what in just the parts of SAP that I cover and deal with directly. I have never encountered a more confusing mess of titles, reporting and seemingly overlapping roles. Back when I did try to keep track of all of this… just when I thought I had it figured out, it would change. So rather than waste cycles second-guessing the organizational structure, I have come to rely on the phenomenal analyst relations (AR) staff to guide me. If there is a better AR team in the industry, I haven’t met them. Yet, while they do a fantastic job, I vote for a simpler organization chart, clearer roles and responsibilities and titles that give you a clue as to what the individuals actually do.

One recent change leads me to believe that SAP is trying. This is the recent announcement of Rodolpho Cardenuto as the head of a new Global Partner Operations (GPO) organization. Prior to forming this organization, partners were covered in a very fragmented way. The new GPO organization consolidates these disparate groups, combining the existing Ecosystem and Channels team, with the SAP® Business One business (which is sold exclusively through the channel), the OEM business and all the company’s strategic partnerships around the world – much simpler.

I know there are some other changes underway and I have to believe some of the jobs that were recently eliminated may have been as a result of “simplification” efforts, since SAP execs made it quite clear this week they are in growth mode, and not contracting.

 

Simpler to Partner?

Speaking of this new GPO organization, partners are becoming increasingly important to SAP. In addition to the strategic decision to sell to small to medium size enterprises (SMEs) exclusively through the channel several years ago, SAP now sees the potential for accelerating growth worldwide by building alternative routes to market through its partner ecosystem, whether this is through added coverage or added capabilities.

SAP has also actively encouraged partners to develop their own “value-add” in terms of industry-specific functionality and other add-on capabilities. The development of new platforms (the HANA Cloud Platform) and an online marketplace directly supports this.

Of course the formation of the GPO organization is one step in the simplification process in dealing with partners. Before, different groups dealt with different types of partners (e.g. systems integrators, global VARs, strategic partners, etc.) However, more and more, partners have taken on multiple roles. Systems integrators also became resellers; global VARS also became strategic partners and co-innovators, etc. In the past that meant they had to deal with different groups within SAP, and those different groups all worked differently.

The formation of the consolidated GPO organization is therefore one more step in the continuing effort to make it simpler to partner with SAP. Of course some of these partners are large companies, like Cap Gemini, Accenture and Deloitte and are well-equipped to deal with complexity. But then there are thousands of partners that are themselves small businesses. Think what it must be like for a small Business One reseller to deal with a company like SAP. I first saw these simplification efforts get underway about 4 years ago when Kevin Gilroy came on board. One of his first tasks was to simplify contracts. Don’t quote me on the page count, but I think before Kevin arrived, the contracts were upwards of 30 pages or more. He proudly brought a two-page contract to Bill, who promptly told him to get it down to one.

The partner management team has made great strides already in making it simpler to partner with SAP, and this week I saw a new partner portal that will likely make the life of a partner much easier. It is a single point of entry, easily searchable, to access all the assets and resources SAP provides. This is free, but for an added fee, partners can also sign up for the SAP Learning Hub, which brings additional virtual educational directly to the partners.

Bottom line: I think the simplification efforts have been successful and will continue to make it easier for partners, which will in turn allow them to spend less time figuring out how to deal with SAP and more time servicing the customer.

Easier to Do Business With?

But what about the customers that deal directly with SAP or even indirectly through partners? Often questions of ease of doing business boil down to pricing. One analyst in a press conference this week asked about simplifying pricing, citing Oracle’s policy of publishing its price list for all to see. I would caution anyone against confusing transparency with simplicity. Oracle might publish prices, but good luck in trying to figure out what anything will really cost, because its pricing is far from simple.

In all fairness though, any ERP vendor struggles with this, particularly those with broad portfolios. SAP has already taken steps to further simplify its pricing structure, particularly around the bundling of HANA, but any prior efforts were dwarfed with one announcement this week: Fiori apps are free. Here is the announcement:

SAP AG today announced that SAP Fiori user experience (UX) and SAP Screen Personas software will now be included within underlying licenses of SAP software. For existing customers [those who already purchased], SAP will provide a software credit redeemable against future software sales. In addition, SAP will offer a portfolio of UX services, including design, rapid deployment and custom development, to enhance customer engagement. SAP users can now take advantage of a next-generation user experience based on modern design principles setting a new standard in the industry.

This announcement is huge, for a couple of reasons. First of all, it really does help to simplify the pricing because there is no price. From the moment Fiori was released with a modest price tag, the hue and cry from customers and industry observers was that it should be free. This perception was largely based on the fact that the first 25 Fiori apps simply changed the user experience and added no new features and functions.

A new user experience adds “value” in of itself but no further value was added, so it is understandable that customers would expect their maintenance dollars would pay for this. In addition, because Fiori largely just delivered a new user interface, many customers and industry experts alike lost sight of the fact that they were indeed developed and delivered as apps. They thought SAP had just gone into the presentation layer and changed the user interface, as it would have for an upgrade. That was never the case and now the Fiori apps that are being developed go well beyond changing the user interface. The SAP Smart Business Cockpits being developed now are changing business processes and delivering very significant added features and functions.

These cockpits address a variety of functions and roles throughout the organization, including:

  • Cash management
  • Sentiment analysis
  • Bank analyzer
  • Demand forecasting
  • Bulk pricing scenarios
  • Mass execution of availability checking
  • Transportation asset management
  • MRP cockpit
  • Transportation management
  • Purchasing
  • PLM Variant configurations
  • An accounting hub
  • An “exposure” hub

These will be delivered over the next year or so. I am sure I have missed a few, but you get the picture. What does this have to do with simplicity? All of these are being developed as Fiori apps, which means there won’t be an SAP salesperson knocking on your door to sell them to you. They are released on a quarterly basis and they are free. And because they are delivered as “apps” and not as traditional “enhancements” you don’t have to go through a complete upgrade cycle to get the one (and only one) you are interested in. You just implement that one app.

This essentially paves the way for SAP to reinvent the Business Suite from the outside in, without causing a major reimplementation along the way. I think this added value was overshadowed by the declaration of victory by ASUG in having won the battle over charging for Fiori apps and the fact that many are still thinking Fiori is just a new user interface.

A Simpler Solution?

Which brings us to how the “Simple” or “Simplify” message pertains to the SAP products. The best example of the impact is probably the introduction of a new product, “Simple Finance.” Don’t let the name fool you – it is not just for small companies that might have simple accounting requirements. SAP itself made the transition to this product and is now running its financials with it. And I heard it made that transition over a weekend.

I myself don’t have as clear a picture of this as I would like, since my packed schedule at SapphireNow often conflicted with sessions and discussions on the topic. So I will turn to the dynamic duo of Jon Reed (@JonERP) and Dennis Howlett (@dahowlett) to add some insight since they spent some one on one (or two on two?) time with Hasso Plattner and new head of development Bernd Leukert on the topic. Den and Jon published this to better explain SAP’s cloud strategy, and indeed Simple Finance was developed as a cloud offering. But this excerpted section is perfect for the point I am trying to get across:

Plattner and Leukert confirmed that the freshly-named ‘Simple Finance’ is part of a broader rewrite/re-imagining of SAP ERP, with HANA and cloud as the enablers. Referred to as the ‘simple suite’ or the ‘S system,’ Leukert said that the monstrous ordeal of rewriting 400 million lines of business suite code was not necessary, because of a “massive reduction in code” resulting from the simplification HANA allows and in particular, the elimination of bulky aggregates which account for a significant percentage of current code.

This simple suite, currently focused on the Simple Finance area also includes an aggressive paring down of software accounting complexities, a now-familiar talking point of Plattner’s.

While anyone can see the value of massively reducing the amount of code required, the non-technical person might not immediately appreciate the significance of the elimination of aggregation. Forgive me for over-simplifying, but think of it this way. Traditionally accounting solutions have accumulated all sorts of totals. Some are for periodic reporting (monthly, quarterly, annually, etc.), while other aggregates are used to gain insight into different parts of the organizational structure. This aggregation enables reporting without having to sort and calculate totals across a potentially large volume of transactions. Sounds simple and effective because you can gain access to these totals through a simple query. But there were some drawbacks.

Not only is there embedded code to maintain these aggregates, but sometimes these totals are not updated in real-time, and instead are calculated with batch runs. That means you are looking at a snapshot in time and not the “real” number. Secondly, what happens when you want to change the organizational structure and report in a new way? Those pre-calculated totals are now meaningless. If you can instantly slice and dice and calculate on the fly using any criteria, you don’t have to do any of this aggregation and you get complete flexibility.

This flexibility and speed is the real value HANA brings to the business, along with improved, faster decision-making. If SAP can deliver this simpler suite through a combination re-writing code and adding Fiori apps, I believe the SAP products will undergo a dramatic transformation.

Of course, even if this happens, SAP’s competitors won’t let go of the message that SAP is big, clumsy and complex any time soon. They will still be inserting that FUD (fear, uncertainty and doubt) in the minds of prospects as long as there is a shred of truth to it. That only makes it more of a challenge for SAP.

Conclusion

SAP will never deliver Simple. But it can Simplify. These are just a few of the ways. While I believe SAP has already made progress, it still has a long way to go to deliver simplification. But I do believe it is committed at the very top of the organization. But the buy-in has to permeate throughout the ranks. I believe some of the SAP folks will need a frontal lobotomy to make this transition, but many more will be breathing a sigh of relief. They, like SAP partners and customers, will say, “Finally.”

 

 

Tagged , , , , , , , , ,

Insights from SAP Insider BI2014 – BI for the Business User?

Those of you who follow me (and my blog posts) might have scratched your heads a bit earlier this week when you saw me Tweeting from the SAP Insider BI event. After all, I generally write for an audience of business users and let’s face it, it is the IT department that buys and uses BI tools. Well, I was there because of all the exciting new advances in BI tools and technology that have the potential to assist you, the business user in gaining insights and intelligence about your business. But more importantly I was there because so few of you are screaming for these new tools. As Steve Lucas, President of SAP Platform Solutions, said on stage, “When was the last time a business user came up to you and asked for more middleware?” Bingo! As business users, you don’t want more (or any) middleware; you want answers to your questions and solutions to your problems. The problem is, many of you have become so frustrated waiting (too long) for simple things, like a new piece of data added to a report, that you’ve stopped asking.

Case in point: You also might have noticed that you only heard from me during the opening keynote. Why? Did I just breeze in and out? Did I lose interest? Was there nothing else of importance to comment on? None of the above. After that first keynote I was never able to actually connect through the network available in the other meeting rooms. In the “Happiest Place on Earth” (yes, we were at a Disney resort), it didn’t make me very happy to have no access to Twitter, HootSuite or any of the other platforms I would have used to communicate. But actually saying “never” is a bit misleading. The reality was, after the first few (or dozen) attempts, I gave up trying. And that’s exactly what happens to the business user in search of the next bit of “intelligence” needed to make a serious impact on the business. After a certain period of frustration (minutes in my case, years in yours) you just assume it is too difficult and it is not worth asking.

While some of this new technology is new enough to be bleeding edge, and not everything that gets presented and discussed is generally available, I can tell you: Now is time to start asking for more. Yes, there will be a price tag, but when did you ever get something for free that really added value? And if it adds enough value, it should pay for itself in a reasonable period of time. But in order to find that potential value-add, you might have to start thinking out of the box. In fact, maybe you should re-evaluate problems that were deemed unsolvable in the past.

That is certainly the case when it comes to predictive analytics. Everyone would love to forecast, predict and plan accordingly, but hardly anyone is really doing it today. I grew up (professionally) in the world of manufacturing. Everyone knows there is one universal truth about the forecast: It is always wrong. It’s just a question of how wrong it is. Of course there are all sorts of different forecasting tools and models to use, but the problem is, they are usually very complex and only as good as the input provided. And how does the typical businessperson know which variables really matter? Are some truly indicative of cause and effect, or is it just a correlation? Do you really understand the difference? What if you didn’t have to?

What if you had a tool that allowed you to just throw a lot of variables at the problem? What if you had a tool that was smart enough to pick out the ones that matter and come back with a prediction with a 99% confidence level? That’s exactly what SAP InfiniteInsight is supposed to do. Never heard of it? I’m not surprised. First of all, the name itself doesn’t exactly speak volumes about what it does. I am a firm believer that the name of the product should tell you (or at least hint at) what the product does. There is really nothing in InfiniteInsight that even implies prediction.

Also, the product comes to SAP through acquisition. The acquired company is KXEN, formerly a privately-held San Francisco-based company. Its specialty:  the automation of (at least many aspects of) prediction so that business users can make forward-looking decisions. So does this mean this is a self-service function and the business user doesn’t have to wait for the technical staff to do something? Not really. Those variables the business user wants to throw at the model? Well, someone has to know where they are and how they are represented in the grand scheme (or schema).  But that should be relatively easy for the technical staff and tech-savvy business analysts might also be able to construct the model. So we’re not talking days or weeks; we should be talking hours. This makes the whole process that much more dynamic. How many times have businesses stuck with a forecasting model that was known to be flawed or no longer reflected the real business environment (after all, things change over time) just because it was too difficult and time-consuming to change?

Production forecasts, sales and operations planning and financial planning are just the tip of the iceberg here though. Getting accurate predictive analytics will become contagious. Get good results in one area and you will start to think of all the other ways you would like to “predict.”

And how many times have massive volumes of data sat largely dormant because there weren’t tools to handles such volumes in real time? Those days are also gone. While the Internet of Things is all the rage right now and spells huge opportunities in many different disciplines, this is not a new problem for manufacturers. Many have been collecting these massive volumes of data from sensors on the shop floor for years. And while these sensors might have the ability to shut down an automated production line as temperature or viscosity or any number of other measures start to drift out of tolerance, how many are able to accurately predict when that might happen?

Since preventive maintenance also causes a line to shut down production, timing is critical. Shut it down too early and you lose more production. Wait too long and you pay an even greater price. And yet without the ability to not only collect, but also process and analyze colossal volumes of data in seconds, that data is massively underutilized. Moving data off storage devices and into memory is the key to improving speed and in this case SAP will turn to HANA.

And finally, a third SAP product will play a key role in drawing the business user out of his or her complacency. All the predictive capabilities and all the speed and processing power in the world will be meaningless to the business user if the tools can’t present the results in a meaningful way. That’s the problem SAP Lumira is intended to solve.

Here’s another product name that doesn’t tell you what it does. No it doesn’t treat rheumatoid arthritis or diabetic nerve pain. Does it illuminate data? Hard to say. But even though it doesn’t tell you what it does, the name has a couple things going for it: it’s short and it doesn’t say the wrong thing; it makes you ask what it is. Here’s what SAP says it does:

“Gather and quickly make sense of your data with SAP Lumira, our easy-to-use, data visualization software. In just a few clicks, you can combine and visualize data from multiple sources – presenting both big picture and granular insights in a single view. Use a drag-and-drop interface to create beautiful visualizations, explore data, and share insights with your team.”

Does this mean as a business user you can do it yourself? My guess is, you will still need some help from IT or that tech-savvy super user. Because you still need to know how your enterprise data is organized. But if you have data in spreadsheets now (and who doesn’t?) you can download it for free and try it out for yourself. You’ll educate yourself on the different possibilities and perhaps even come up with those new (out of the box?) ideas.

The bottom line: you don’t have to be a BI expert or a techie to gather more intelligence and insight today. And you don’t have to be a psychic to predict the future. But if you sit back and think all this stuff is too difficult and time-consuming, you better hope your competitors aren’t figuring out that it isn’t.

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

SAP Business Suite on HANA: Changing the Conversation

It’s Not About the Technology, It’s About the Business

I recently got an update on SAP Business Suite on HANA from Jeff Woods, former industry analyst, currently Suite on HANA aficionado at SAP. Jeff had lots of good stuff to share, including some progress to date:

  • 800+ Suite on HANA contracts have been signed
  • 7,600+ partners have been trained
  • There are 200+ Suite on HANA projects underway
  • 55 of these projects have gone live (and the number is growing)
  • The largest ERP on HANA system supports 100,000 users

So the Suite on HANA is quite real. But the single message that resonated the most strongly with me: the conversation has (finally) changed. While we’ve been hearing about HANA as this wonderful new technology for several years now, for the most part, the talk was about technology and even when the technologists spoke about purported business value, they spoke in very technical terms. But the audience I write for, business leaders in various industries, don’t care about technology for technology sake. Many don’t (care to) understand tech-speak. But they do care about what technology can do for them.

A Year Later…

It was just about a year ago that SAP announced the availability of SAP Business Suite powered by HANA, complete with live and live-streamed press conferences in both New York City and Waldorf, Germany. I don’t think I have ever seen such genuine excitement from SAP folks as was displayed in this announcement, and yet the “influencers” in the audience were a bit more subdued. A year ago I attributed this to the fact that these same influencers tend to be a quite jaded bunch, hard to impress. We had also been hearing about HANA for a few years already. There wasn’t a “newness” or game-changing feel about the announcement. But impressing the influencers is only one step towards the real goal of engaging with prospects and customers.

A year ago I also wrote, “SAP is trying hard to change the conversation to be less about the technology and more about the business value.  What is the real value? In the words of one early adopter: HANA solves problems that were deemed unsolvable in the past.” But uncovering those previously unsolvable problems required some visionary thinking.  Tech-speak is not going to get the attention of the guy (or gal) that signs the check or spur that kind of thinking. And a year ago the conversation hadn’t changed. Just look at how the vision of HANA was portrayed:

  • All active data must be in memory, ridding the world of the “rusty spinning disk”
  • Full exploitation of massively parallel processing (MPP) in order to efficiently support more users
  • The same database used for online transaction processing (OLTP) and analytics, eliminating the need for a data warehouse as a reporting tool for OLTP to support live conversations rather than “prefabricated briefing books”
  • Radically simplified data models
  • Aggressive use of math
  • Use of design thinking throughout the model

Look carefully at those words. They mean nothing to the non-technical business executive. Sure, those words got the attention of some forward thinking CIO’s, and that was enough to kick start the early projects, projects that produced amazing results. But that’s as far as the message got. And even when the message was not articulated in technical terms, it was presented at too high a level of abstraction. Business executives faced with important decisions don’t think in terms of “becoming a real-time business.” Operational managers don’t seek out “transformative innovation without disruption.” They want to get through the day most effectively and efficiently and make the right decisions.

Asking the Right Questions Today

So how do you change the conversation? By asking a different kind of question. Because “faster” is universally accepted as a good thing, in the beginning the HANA conversation might have been kicked off with the question to the CIO: What processes are running too slowly today? But in talking to the business user, you need a different approach. SAP’s “cue card” below is a good start. You are now seeing conversation starters that make more sense to the business leader. Take the time now to read them carefully. If you are a business leader, they will resonate much more than discussions of MPP and column-oriented databases or even speed of processes. I especially like the business practice questions in the rightmost column.

Cue card

Source: SAP

But if I were sitting across the table from a business leader, I might ask questions that are even more direct and down-to-earth. For example:

  • Describe a situation where you have to hang up the phone, dig deeper and get back to your customer or prospect later. (By the way Jeff’s thought was that by hanging up you only encourage them to pick up the phone and call your competitor.)
  • What summary data do you get today that consistently requires more detail before you make a decision? Can you get at that data immediately (no delays) and easily (no hunting around)?
  • What level of granularity are you forecasting revenue? Is it sufficiently detailed? Are you forecasting by region or maybe by product line when you would love to be able to forecast by territory, individual customer and individual product combined?
  • Are there decisions that require you to consult with others? How much time does this add to the decision-making process? How easy or hard is it to keep track of who to contact? How quickly can you make contact? Quickly enough?

The goal really is to improve the business not only in small linear steps, but also to increase speed of decision and therefore efficiency exponentially. The first step is to provide new ways of engaging with the system, which means changing the user experience. But to change the game, you need to make improvements to the process itself. SAP’s new Fiori applications are a good example of this progression.

 Fiori: More Than Just a Pretty Face

Last spring, SAP announced SAP Fiori, a collection of 25 apps that would surround the Business Suite, providing a new user experience for the most commonly used business functions of ERP. While useful in pleasing existing users and perhaps even attracting new users within the enterprise, this first set of apps just changed the user interface and did not add any significant new functionality.

The latest installment has 190+ apps supporting a variety of roles in lines of business including human resources (HR), finance, manufacturing, procurement and sales, providing enhanced user productivity and personalization capabilities. The apps offer users the ability to conduct transactions, get insight and take action, and view “factsheets” and contextual information. The next round of Fiori apps are expected to add even more new capabilities, thereby taking them to the next level in changing the game.

The MRP cockpit is an example of this next generation Fiori app and a perfect illustration of how these new apps can recreate processes, even ones that are 30 years old. If you “know” manufacturing, you probably also know that the introduction of Material Requirements Planning (MRP) software back in the late 70’s was transformational, although nobody really called it that back then. “Transformative” innovation is very much a 21st century term. But it truly was game-changing back in the day.

Last year, even before the conversation had shifted, I saw the parallels between the potential for HANA and the automation of the planning process that MRP brought about. Today the MRP cockpit delivers on that potential.

For those outside the world of manufacturing, in a nutshell, MRP takes a combination of actual and forecasted demand and cascades it through bills of material, netting exploded demand against existing inventory and planned receipts. The result is a plan that includes the release of purchase orders and shop orders and reschedule messages. While the concept might be simple enough, these bills of material could be many layers deep and encompass hundreds or even thousands of component parts and subassemblies. Forecasts are educated guesses and actual demand can fluctuate from day to day. Without automated MRP there is simply too much data and complexity for a human to possibly work with.

As a result, prior to MRP, other ways of managing inventory became commonplace. You had simple reorder points. Once inventory got below a certain point, you bought some more, whether you actually needed it or not. You also had safety stock as a buffer, and the “two bin” system was quite prevalent. When one bin was empty, you switched to the other and ordered more. These simplistic methods may have been effective in some environments, but the net result was the risk of inflated inventory while still experiencing stock outs. You had lots of inventory, just not what the customer wanted, when it wanted it. And planners and schedulers still had to figure out when to start production and they knew enough to build a lot of slack time into the schedule. So lead times also became inflated and customer request dates were in jeopardy.

Once MRP entered the picture, these were seen as archaic and imprecise planning methods. Even so, most didn’t rush right out and invest in MRP when it was first introduced. In fact now, decades later, the adoption rates of MRP in manufacturing still sits at about 78%. Why? The existing practices were deemed “good enough” and, after all, that’s the way it had always been done.

It required a paradigm shift to understand the potential of MRP and the planning process executed by MRP was complex. Not everyone intuitively understood it. And if they didn’t really understand, planners were unwilling to relinquish control. Particularly since MRP runs were notoriously slow.

It was not unusual for early MRP runs to take a full weekend to process, and during that time nobody could be touching the data. This didn’t work so well in 24X7 operations or where operations spanned multiple time zones. Of course over time, this was enhanced so that most MRPs today run faster and can operate on replicated data, so that operations can continue. But that only means it might be out of date even before it completes. And MRP never creates a perfect plan. It assumes infinite capacity and “trusts” production run times and supplier lead times implicitly. So while most planners were relieved of the burden of crunching the numbers, they were also burdened with lots of exceptions and expedited orders.

Yet over time, MRP brought a new dimension to material planning. It brought a level of accuracy previously unheard of and helped get inventory and lead times in check. Manufacturers have experienced an average of 10% to 20% reduction in inventory and similar improvements in complete and on-time delivery as a result of implementing MRP.

But through the past three decades, MRP hasn’t changed all that much. Yes it has improved and gotten faster, but it hasn’t changed the game because it still involves batch runs, replicated data and manual intervention to resolve those exceptions and expedite orders. Now with HANA we’re not talking about speeding up the processes by 10% to 20% but by several orders of magnitude, allowing them to run in real time, as often as necessary. But if it was just about speed, we might have seen this problem solved years ago.

You probably don’t remember Carp Systems International or Monenco, both Canadian firms that offered “fast MRP”. Carp was founded in 1984, and released a product in 1990 bringing MRP processing times from tens of hours down to 10 minutes. It ran on IBM’s RS6000 (a family of RISC-based UNIX servers, workstations and supercomputers). But it was both complex and expensive for its time ranging in price from $150,000 to $1 million). Not only was it expensive and required special servers, in order it to work it needed to replicate the data and then apply sophisticated algorithms.

About the same time Monenco introduced FastMRP, also a simulation tool, but one that ran on a personal computer. While it cost much less than Carp’s product, it was also less powerful and had significantly fewer features.

You won’t find either of these products on the market today. If speed was all that was required they would have survived and thrived. In order to change the game, you also need to change the process, which is exactly what SAP intends with its new Fiori app for MRP.

The new MRP cockpit includes new capabilities, like the ability to:

  • View inventory position looking across multiple plants
  • Analyze component requirements with real-time analytics
  • Perform long term MRP simulations
  • Analyze capacity requirements and suggest alternatives

But this too requires a paradigm shift. Manufacturers, as well as other types of companies, are quite accustomed to making decisions from a snapshot of data, usually in report format, possibly through spreadsheets. They have become desensitized to the fact that this snapshot is just that, a picture of the data, frozen in time.

What if you never had to run another report? Instead, whenever you needed a piece of data or an answer to a question, you had immediate and direct access, not to the data as it was at the beginning of the day, or the end of last week, but to the latest data in real time? Not only will decision-makers need to adjust to thinking in real-time, but will also have to trust the software to automate much of the thinking for them. Will they be able to sit back and let the software iterate through multiple simulations in order to find the best answer to an exception even before it is reported as an exception? I suspect they will if it is fast enough. And HANA is now delivering at speeds that just a few years ago would have been impossible. But with these speeds accelerating by orders of magnitude, the ability to communicate and collaborate effectively must also accelerate.

Making the Human Connection

It is not enough to change the way users engage with the software, it is also necessary to change the way they engage with other people. How often do you or your employees today express sentiments like:

  • If I just knew who to contact for approval/help….
  • I don’t know what to ask
  • I wish I could check with (several) people on this quickly

What if the software could help? As work flows are streamlined, automated and accelerated, so must the lines of communication and potential collaboration. Whether employees are looking to move a process forward, resolve an issue or mature an idea faster, lack of communication and clumsy modes of collaboration can inhibit the game-changing effect of the technology. Which is why SAP has upped its game in the area of Human Capital Management and social collaboration tools. It took a significant step forward with the acquisition of SuccessFactors and JAM and has been blending these capabilities with the HANA platform.

Key Takeaways

Nobody today would disagree that the SAP Business Suite, powered by HANA combines deep and rich functionality with powerful technology. But can it be game changing in terms of how businesses operate? The potential certainly exists, but it’s not just about speed. Changing the game means changing the way we’ve been doing things for decades. Before we can change the process, we need to change the conversation. Are you looking to optimize business processes? Are you ready to talk?

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

SAP’s Next Generation ERP: HANA and Fiori Help Customers Explore Final Frontier

Continuing our “Star Trek” series, this is the first of several posts specific to vendors offering various renditions of “next generation ERP.”

In previous posts (you can find links to the right), Mint Jutras had some fun using a Star Trek analogy to describe the next generation of ERP in terms of new technology that enables:

  • new ways of engaging with ERP
  • custom configuration without programming
  • better integration
  • more innovation

We predicted the core functions of ERP would retreat “into darkness,” surrounded by newer, easy to consume, intuitive consumer grade apps that would deliver innovation and competitive advantage. We also hinted at even newer technology that would power your ERP to operate at warp speed.

SAP HANA is that newer technology that could potentially propel your ERP into overdrive. Additionally, back in May SAP  announced SAP Fiori, a new collection of 25 apps that would surround the SAP Business Suite, providing a new user experience for the most commonly used business functions of ERP. Can the combination of these two technologies and other innovation being delivered by SAP allow its prospects and customers to explore the final frontier and boldly go where no ERP user has gone before?

Can SAP Really Be Nimble and Quick?

SAP’s competitors love to sell against them by saying its ERP is big and complex and anything but user-friendly. They point to long, difficult, multi-million dollar implementation cycles. Of course they conveniently forget that many of these implementations are massive simply because the large enterprises themselves are more massive. Rolling out a solution to operating locations in multiple countries around the world is easier with modern, web-based solutions, but it is still not an easy task.

Competitors assume all deployments are heavily modified and use words like “monolithic” and “outdated” to imply SAP customers are locked in to a solution that is over-priced and under-delivers. It is true that many of these are very mature implementations that were installed and implemented when all solutions were developed as tightly integrated, monolithic solutions using tools that would seem archaic today. These older implementations are far more likely to have undergone invasive customization than would be required today. But unless the competitor is relatively new on the scene, it too is likely to have customers on legacy versions of older products, facing the same kind of challenges.

Competitors and pundits love to liken innovating SAP’s ERP to steering a battleship: Big and powerful, but difficult to steer and change direction. In contrast, competitors describe their own solutions as lighter weight, flexible, agile, and modern. They will proudly tell prospects that their solutions aren’t the big battleships, implying they can indeed innovate faster. That may or may not be true. All you can be sure it means is that their solutions don’t have the depth and breadth of functionality.

In all fairness, competitors’ customers and prospects might not need that same depth and breadth, particularly if the vendor targets small and/or mid-size companies, or perhaps specific verticals, micro-verticals or even a niche market. SAP Business Suite is a strong solution for mid-size to large to mega-sized enterprises in 21 different industries, some of which can be further broken down by micro-vertical.

But what many of its detractors miss in using this “battleship” attack strategy is the simple fact that SAP stopped innovating the battleship itself several years ago. Does that mean it’s ERP solution is dead or dying? No, far from it.  It means it has all the basics down pat. And the very basic of basic requirements haven’t changed in decades. Basic functions like accounts payable, accounts receivable, inventory control and purchasing haven’t changed and they aren’t rocket science.

Of course, all functions and processes evolve in some ways. Take accounts payable, for example. While we still receive materials, match receipts to invoices and pay suppliers, the options for payment have indeed changed. Electronic payments are fast making printing checks obsolete. And for that matter, we receive fewer and fewer paper invoices that have to be manually matched. Automated processes have allowed us to turn clerks into knowledge workers. So we do more spend analysis and supplier collaboration.

All these new ways of doing things require new features and functions in our supporting ERP. But notice that all these are new tasks to be added to the core basics. They can be developed and delivered as separate components without changing the direction of the battleship or the battleship itself.

And is being a battleship all that bad anyway? An aircraft carrier is a battleship in the context of modern warfare. No it can’t turn on a dime in order to attack. It steams to a strategic location and it can then pinpoint any target within a wide radius. Why? Because the aircraft carrier is simply the base of operations from which the fighter planes can attack in any direction.  The carrier provides support and fuel much like ERP provides data. The planes must “fit” the ship, as they must be tethered on landing, just as components must be integrated to ERP. But, like the planes on the ship, they are loosely coupled rather than tightly bound. And providing the planes use standard fittings, one plane might be swapped out for another with relative ease, just like the next generation ERP modules that use a standard definition of a business object.

This is exactly how SAP has continued to develop new features and functions over the past several years in spite of having stabilized core ERP. The concept was first introduced circa 2006 with the introduction of its enhancement packs. The approach was to bundle enhancements together periodically in feature packs, but allow customers to selectively implement individual innovations without having to upgrade the entire solution.

As SAP’s cloud strategy has developed more recently, so has its object-orientation of development. Take for example its latest release of Cloud for Sales (initially named Sales On Demand).  In order to be an effective piece of customer relationship management (CRM) it needs access to a customer master file. But if you have SAP ERP, you already have a customer master file.

Think of the customer (master data) as a business object. An older ERP solution will build that customer master file (the business object) right into the solution. Instead, SAP treats the customer master as a separate business object that lives outside of the application. By doing this, both applications can point to, access and reference the same business object.

But what about file maintenance? Instead of building the maintenance functions directly into each application, SAP treats that function as a separate function as well. Instead of building that directly into Cloud for Sales and SAP ERP separately and individually, SAP builds it once and puts it in a “business process library” which both (and other) applications can use. This approach allows additional components of functionality to plug into these applications much like the fighter planes plug into the carrier upon landing.

A New User Experience

So far our analogy of a battleship (a.k.a. aircraft carrier) has been sufficient, but a ship on a sea hardly represents a “final frontier.” How do we then turn that ship into a starship? We’re not really as far off as you might think because in some ways, the USS Enterprise operated much like a traditional battleship. You didn’t really see it landing on the surface of those alien planets. Like a carrier, it parked itself strategically (in orbit around the planet) and used another means of transportation for that final approach.

Shuttlecraft were the equivalents of a fighter plane or a helicopter, but they weren’t used very frequently. More often the crew of the Enterprise used Chief Engineer Scott’s transporter beam. In a sense it didn’t add new functionality. The function was to get people from point A to point B – not a new sort of thing. But it certainly added a new user experience. You might even call it the consumerization of space travel.

That is exactly the concept SAP has applied to its newest product, Fiori. SAP estimates that 80% of SAP users “experience” the solution through older technology today. Fiori sets out to change that without necessarily adding any new features or functions. SAP has taken the most commonly used screens and applied what it calls the 1-1-3 rule: one use case, one user, no more than three screens. The screens will typically include one as a “to do” list, a screen with more details and a sub-screen where the user takes action.

These new apps can be run from any kind of device, from on-premises or in the cloud. This potentially opens the door for more users and a different kind of user. These apps are easy to use, but also easy to customize. If you can pretty up a PowerPoint slide you can customize the look and feel of these apps. Executives that have previously been loath to touch ERP because they just didn’t have time to “figure it all out” will no longer have that excuse. Answers to questions will be a few clicks away on their smart phones and tablets.

The selection of which screens to revamp was not random. SAP has the ability to actually measure usage of different functions within the Business Suite, providing its customer grants permission to do this. Many of them have and after analyzing this data, SAP selected a set of 25 apps, which it feels covers the top 40% of usage. This set of 25 is likely to expand but SAP doesn’t expect it to blossom into thousands of screens. It will continue to focus on those functions most widely used in the course of conducting business.

SAP customers will have to pay for this, but a single, modest license fee is charged for the entire set of applications. SAP is not looking to make lots of money but also understands that putting a price tag on it conveys value.

Turning the Battleship Into a Star Ship

All this is great, but adding additional components of functionality and a new user experience doesn’t necessarily turn a battleship into a star ship. A star ship traverses beyond our own solar system; so it definitely needs to travel at warp speed. Otherwise it would take more than a lifetime in order to reach remote parts of the galaxy. Decision-makers need access not only to data from structured applications within their enterprise applications, but also to vast treasures of previously unexplored data from the Internet: news feeds, customer sentiment, social media, etc.

So to conquer the final frontier of ERP exploration, you need speed: Speed not for the sheer sake of speed, but with a functional purpose.

That’s where HANA comes in. Neither the Business Suite nor Fiori require HANA in order to run. Existing customers can benefit from this next generation functionality without transitioning to HANA. But if they don’t, they won’t be on the ERP equivalent of the starship Enterprise.

SAP HANA Enterprise Cloud: Speed, Power and the Benefits of Cloud Delivered Faster provides more detail about the speed HANA brings, along with the benefits of operating in the cloud. But the benefits of speed are equally applicable in a traditional on-premises environment as well. Suffice to say, with HANA, batch processes become obsolete. Processes like Material Requirements Planning (MRP) and sales forecasting that used to take hours to process can be reduced to minutes, or even seconds, without constraining the amount of data processed. This adds a whole new “real time” dimension to decision-making.

Key Takeaways

To operate effectively in the uncharted territory of global competition today, enterprises need vehicles that will carry them into the future.  Monolithic, outdated ERP built on old technology won’t get you there. You need the next generation of ERP to provide new ways of engaging with ERP. You need new ways of tailoring it to your own individual needs, without building barriers to moving forward. You need new innovation delivered as components that can be easily integrated to your core ERP.

SAP has been on this path to next generation ERP longer than most, delivering new innovation in an innovative way. SAP Fiori and SAP HANA are simply the next steps that will help companies venture into the final frontier. The real question: Do you have the necessary vision and are you ready to boldly go where no ERP has gone before?

Tagged , , , , , , , ,

Rumors of the Death of SAP Business ByDesign Greatly Exaggerated

I have been hearing rumors about the death of SAP Business ByDesign for several months now. Most of them come to me from SAP competitors, although a few have come through ex-employees. Note the emphasis on “ex.” No employee of SAP has ever confirmed or even hinted at this. However I have to admit the messaging around Business ByDesign has not always been crystal clear, which has allowed for these rumors to spread.

Prior to the SuccessFactors acquisition Business ByDesign was positioned as the platform of choice for development of all cloud offerings. But with the acquisition and the accompanying infusion of “cloud DNA” that story changed. All of a sudden the Business ByDesign platform wasn’t important. The powers that be at the time (SapphireNow May 2012) said,  “Customers don’t care about platforms. They only care about beautiful applications.” We heard less about By Design and more about the benefits of loosely coupled applications over tightly integrated ones. The market interpreted that to mean that Business ByDesign would be broken apart into different bits and pieces and might not survive as an integrated suite. SAP didn’t go out of its way to squash that rumor, so it too spread.

Then came Sapphire Madrid (November 2012) and there was a new platform in town. The HANA cloud platform started showing up on slides with little or no fanfare, and less explanation. The more SAP talked about its cloud strategy, the less we heard about Business ByDesign. Hence more confusion.

Until now

Earlier this week SAP presented a Business ByDesign strategy update to several industry analysts, including yours truly. Most importantly, it positioned Business ByDesign relative to other products in its portfolio. While I often find SAP graphics confusing in that they are too technical and attempt to say too much, I found the graphic shown refreshingly effective.

BBD

But it does assume you know something about SAP products, so let me explain. Business ByDesign is essentially a midmarket product, targeting companies that are smaller than the very large enterprises where the Business Suite is sold, and companies that are bigger than the SMBs which is the intended market for Business One. Business ByDesign shares this space with Business All in One, which sits a little higher. Remember, Business All in One (BAiO) is essentially the same underlying ERP that is a big part of the Business Suite. But BAiO bundles ERP with industry-specific content and best practices to make it a better fit and an easier implementation for those midmarket companies in (many) supported industries – midmarket companies that don’t have quite the deep pockets of the large enterprise.

You’ll notice BAiO also dips down into the Business ByDesign space. Business ByDesign is SaaS; BAiO is not, although SAP does offer some cloud alternatives for the Business Suite and BAiO, which have traditionally been deployed on-premise. But these cloud options are more like a hosting environment than SaaS. This overlap might result because of deployment preference or it might result because industry-specific requirements are not be satisfied with the Business ByDesign suite.

But you will also notice the Business ByDesign block extends upward into the top of the midmarket and also encroaches on the large enterprise space as well. Business ByDesign will be offered as two different packages, under two different names, but with one single code base. Business ByDesign is the complete suite, while SAP Cloud for Financials is a subset, including the finance and accounting piece of ByDesign. Even though it will share a code base, the code base was tweaked so that SAP Cloud for Financials could stand alone, without the other non-accounting “legs” of the solution.

The reasoning behind this split into two packages is to address two different buying patterns. SAP Business ByDesign is intended for “Mid market companies and subsidiaries [that] expect an out-of-the-box ready-to-use suite with open interfaces.” SAP Cloud for Financials (the subset) is for “Large Enterprises [that] expect an open ERP backbone to be complemented with SAP and non-SAP Line of Business applications.” While the Business ByDesign buying pattern is pretty clear, the SAP Cloud for Financials might require a bit more explanation.

Conceptually, these two different approaches aren’t all that different. Few large enterprises today are huge monolithic organizations. Instead they are comprised of operating units, divisions and/or business units. While these units might have some operational autonomy, financials will have to be consolidated at a corporate level. Where these units operate as a separate legal entity, a full ERP solution is most likely needed. While in the past these units may have been left to on their own to select and implement ERP, today, standards are more the norm. The 2013 Mint Jutras ERP Solution Study found 94% of companies (with multiple operating locations) have defined standards for ERP today. What better way to enforce these standards than through a cloud-based SaaS environment?

Where does Business ByDesign fit in this scenario? It fits as an integrated suite at the subsidiary level. A lot of different ERP vendors talk about this two-tier kind of approach. Some even advertise they can integrate with SAP at the corporate level, simply because of SAP’s dominance here. A cloud solution at the subsidiary level has a lot of appeal here because it helps the enterprise assert a level of control while also providing some flexibility and autonomy at the subsidiary level.

But how about if we pull a switch here? What if we start to think that maybe the corporate financials might be due for an update or even a major overhaul? With the siren call of the cloud becoming more and more compelling, why not consider replacing that legacy accounting solution at corporate with a modern, technology-enabled, cloud-based solution? You might not think the financial modules of an ERP designed for a midmarket company have the accounting chops necessary to support a large enterprise. But then most accounting applications designed for the midmarket aren’t built by SAP. In fact, SAP can and has used the same design team for Business ByDesign (and therefore SAP Cloud for Financials) that architected the Business Suite. And at that level SAP has dominated for years.

All told, this one simple graphic speaks volumes about the relative positioning of the SAP products. Is there room in SAP’s strategy for three different products (four if you count BAiO, with its separate go-to-market strategy)? I am not only tempted to say yes, I am tempted to say, “Hell, yes.” Think about it. SAP is the 800 pound gorilla and even 100 pound gorillas can handle a diverse portfolio.

Addressing Concerns

So what about some of the accusations and assumptions that have been floating around the rumor mill? Let’s counter a few of them.

“SAP is pushing Business One in the cloud instead of Business ByDesign.”

ByDesign has two characteristics that define it: it is a midmarket suite and a cloud solution that is deployed exclusively as software as a service (SaaS). It was never intended to replace SAP Business One at the low end of the market, but when a small company wanted SaaS ERP, it was the only product SAP had to sell. Now that a “cloud” option exists for Business One, that is no longer the case. This is a clear segmentation of the market by company size. Also, Business One has momentum. With over 40,000 customers and a large and mature channel in place, now that a cloud option is available it is only logical it is starting to gain its own fair share.

“SAP is no longer developing the product.”

SAP has been continuing to develop Business ByDesign, but these efforts might not have been particularly visible over the past couple of years. While SAP Cloud for Financials and Business ByDesign share a common set of code, some effort was involved in order to allow SAP Cloud for Financials to stand alone and yet be easily “coupled” to other solutions. This tends to be “under the covers” work.

And then there is HANA. Business ByDesign pre-dates HANA.  It was built in the NetWeaver era and used MAX DB (database) and TREX (search and classification). In order to take advantage of its advanced technological capabilities, Business ByDesign also had to transition to HANA, resulting in more “behind the scenes” work.

SAP assured those of us on the recent call that it was continuing to invest in the product and the platform. That said, it is also (better) defining the current target market. SAP will focus on developing the ERP backbone and specific capabilities for service industries, while also adding (open) integration capabilities. It will continue the transition to HANA for scale and extensibility. And it will also transition to HTML5 and benefit from the work done on the Fiori applications for a responsive, mobile-first user interface.

“Business ByDesign is a technological dead end. It is based on Microsoft Silverlight.”

See answer above.

“SAP themselves view it as a failure; otherwise it would be available world wide. Instead it is only available in a few countries.”

Twenty four percent (24%) of Business ByDesign business has been in the US and 32% in Germany. But it is available in 15 different countries. Is it concentrating its attention on all 15? No, but then not all 15 of them have really strong economies today. The SAP installed base is a prime market for Business ByDesign so SAP is going where it has the most customers and can make the biggest bang for its buck. That only makes good business sense.

Three more countries are planned for 2013 (New Zealand, Japan and South Africa) and an additional 3 are planned in 2014 (Brazil, Belgium and Singapore).  In addition customers are running customer-specific localizations in another 31 countries.  How many countries does it need to be in?

Summary

The supposed death of Business ByDesign seems to just wishful thinking on the part of some competitors. Although I also observe other SaaS ERP companies welcoming SAP onto their turf, as much for validation as for healthy competition. Let’s face it, all other ERP companies love to single out those competitive deals where they have beaten SAP.

Instead of a death knell, I am seeing renewed focus and commitment across SAP at the board, and executive level, as well as in the field. This represents a commitment to the cloud strategy in general and Business ByDesign specifically. Now, more than ever, SAP is clear about its target for the product:

  • The SAP installed base and upper mid-market are key for the Business ByDesign suite. Customers with higher revenue and user count threshold are prime targets as well as subsidiaries of large enterprises.
  • Large enterprises will be the target for packages such as SAP Cloud for Financials and other line of business cloud solutions like SAP Cloud for Customers and SAP Cloud for Sales. SAP will stress integration capabilities with SAP and non-SAP cloud / on premise systems.
  • Its primary industry focus will be professional services, public services and distribution.
  • While the product is available in other countries, SAP will focus its sales efforts where it has its largest installed base and where economic indicators signal a strong market. As a result, go to market efforts will focus on the US, Germany, the UK, Netherlands, Canada and Australia.
Tagged , , , , , , , , , , , ,

Impressions from SAP Americas Partner Summit: Partners Make it Real

Tis the season for partner summits. SAP Americas Partner Summit was the 3rd of these I attended in a week and a half. This was the first of this type of event for SAP since it recently merged North America and Latin America into a single unit under the direction of Rodolpho Cardenuto, President SAP Americas. This merging of the Americas bucks the trend in the industry. As Latin American economies, most particularly Brazil, continue to emerge, it is more likely for Latin America to be spun off from a previously combined unit.

And the combination of the two Americas has a further bit of a unique twist. Typically North America will be the dominant player, and therefore you might expect it to bring its southern neighbors into the fold. Yet at the Summit, it really felt more like Latin America was taking North America under its wing. Presumably this is largely based on the recent successful growth of Latin America under Mr. Cardenuto’s direction.

Over the course of two days we heard lots from SAP executives on the main stage, in smaller groups and one-on-one meetings. Some of what we heard simply reinforced the four pillars we have been hearing about quite consistently at various events over the past year or more, namely how SAP intends to:

  • Leverage the core business applications
  • Deliver in mobile
  • Lead in the cloud
  • Capitalize on big data (read: HANA, HANA, HANA)

But how do these key elements of SAP’s strategy pertain to the partners and the customers they serve?

Leveraging the core business applications

The key message here: industries are important and partners are critical to building out solutions. There will be common processes across all companies. These common processes are easily handled by basic functionality that has become quite commoditized today, making it hard for any software company to differentiate itself solely on the basics. It is equally hard for any customer running “just the basics” to gain a competitive edge.

SAP’s approach to delivering that source of differentiation is to co-innovate with partners and customers. First of all, SAP constructs specific “value maps” for each of 25 different industries, identifying market trends and specific business capabilities required to compete in these markets. It then creates very unique blocks of solutions for each industry.  The goal is to not just deliver technology, but to create more value for its customers, and therefore SAP is taking a design thinking approach. This has been music to my ears, which are tuned more to business issues than pure technology. I spend much of my time and efforts translating techno-speak to business-speak.

Design thinking is becoming more and more popular these days, but in case you are not familiar with the concept, it is a repeatable process for solving problems and discovering new opportunities. It consists of 4 key elements:

  1. 1.    Define the problem
  2. Create and consider many different options
  3. Refine selected directions
    Repeat steps 2 and 3 until you reach…
  4. Pick the winner; execute

As the pace of change accelerates, as technology allows us to solve problems previously deemed unsolvable, SAP understands it can’t possibly deliver all this value itself, and therefore turns to partners. As Chakib Bouhdary, EVP Industry Solutions and Customer Value stated on stage, “We all have to change our tolerance to IP sharing.” This is an important concept and one critical to encouraging partners to develop complementary solutions, along with a go to market plan that includes revenue sharing.

At first glance this “sharing” of IP and revenue might seem to pertain only to the traditional Value Added Reseller (VAR) or the larger service providers/system integrators. But during the Summit SAP also introduced the SAP PartnerEdge program for Application Development, “a simple and comprehensive program designed to empower partners to build, market and sell software applications on top of market-leading technology platforms from SAP.

How is this new and different? Essentially it lowers the cost of entry for small partners, while also simplifying the process of signing up. Partners can choose from a set of “innovation packs” based on the latest platform technologies from SAP, including the SAP HANA platform, SAP HANA Cloud Platform, SAP Mobile Platform, SAP databases and the SAP NetWeaver platform. The innovation packs contain technology-specific license rights, resources and services to help partners rapidly get enabled to develop applications on SAP platforms. The packs are also designed to support custom development for co-innovation with customers, which often is the first step to developing a more commercial, standard application. All for an entry fee of around 2500 euros.

These small partners pay a low annual fee (500 to 1500 euros per year) for each of these innovation packs. In turn they can also offer their wares through the SAP online app store and potentially reach a much broader market and therefore better monetize their efforts. This encourages a larger volume of smaller partners in a very real “win-win” scenario.

Deliver in Mobile

Notice the SAP Mobile Platform is included above as one of the innovation packs. The consumerization of IT has changed expectations of connectivity and accessibility of data. But nobody (in their right mind) really wants to lift and shift the traditional ERP user interface to a mobile device. Mobile executives today want answers to specific questions, hence the increase in demand for more purpose-built mobile apps. Lots of questions potentially generate the need for lots of mobile apps. And the SAP online app store is the perfect place for partners to showcase those they build on SAP’s mobile platform.

Lead in the Cloud

It seems everyone today wants to claim “leadership” in the cloud and SAP is no exception. With all the “mine is bigger than yours” rhetoric in the market today, determining who is on top is difficult and probably a bit subjective. However, after developing its own “born in the cloud” (SaaS only) business management suite (Business ByDesign), two major “cloud only” acquisitions (SuccessFactors and Ariba), 30 million users in the public cloud and the world’s largest business network supporting $460 billion in transactions, SAP has to be right up there on the leader board.

While there is still a lot of confusion over cloud and SaaS, the interest in both has taken a quantum leap over the past couple of years. I’ve written a lot about the benefits of moving to the cloud, but while others predict that very soon the vast majority of applications will be running in the cloud, my research indicates only 33% will be SaaS in 5 to 10 years. I attribute this to the fact that there are so many solutions running on-premise today and many companies are reluctant to rip and replace only to convert to a SaaS deployment model. So does that limit the number of companies that can effectively leverage the benefit of the cloud to those willing to abandon their current software licenses? SAP says, “No.”

Many of the companies running on-premise solutions would love to relinquish the responsibility of managing and maintaining those solutions and reap the benefits of the cloud. SAP’s answer to this is to offer Managed Cloud as a Service (MCaaS). This isn’t a brand new concept. Back in May, SAP announced its SAP HANA Enterprise Cloud. As I wrote back in May…

On May 7, 2013 SAP announced SAP HANA Enterprise Cloud. As the name implies, it is a cloud-based service that allows an organization to move existing (or new) implementations of the SAP Business Suite and SAP NetWeaver Business Warehouse, powered by HANA, off their own servers and into SAP’s massive data centers. Why would an enterprise want to do this? The short answer: Speed, power and the benefits of cloud computing without the disruption of replacing existing on-premise solutions. Speed and power come from HANA, adding visibility and agility to the business by enabling decisions to be made in real-time with volumes of data that were inconceivable just a short time ago. Cloud computing lowers cost and adds elasticity, allowing capacity to stretch as your business and your need for data grows.

This is not SaaS and is not a public cloud. It is really a private cloud for the customer managed by SAP. This was a purposeful decision on SAP’s part since the objective is to make the solution truly “elastic.” While this term may be common in technology circles, it is less so in the business community. Essentially, it means the customer is never constrained by hardware limitations. Data center configurations expand (transparently to the customer) as more computing power is required. And if there are any lingering concerns about applications running in a public cloud, those go away with this model.

So what does this mean for partners and how is MCaaS different? It means they can bring the benefits of the cloud to those not quite ready for a SaaS solution. Partners can purchase product licenses and offer them, along with other services on a subscription basis. While this is the same concept introduced with the HANA Enterprise Cloud, HANA is not a requirement, nor is the Business Suite. SAP may be hosting the software, but partners may also sign up to do the same. SAP Business One and Business All-in-One are already offered in this kind of hosting model by several of the larger partners.

Capitalize on Big Data (HANA, HANA, HANA)

This was the first SAP event I have attended in a long while where HANA was not the primary focus. Yet its presence was certainly implied, if not directly referenced. Steve Lucas, President, SAP Platform Solutions talked a lot about “the real time connected enterprise:”

  • Real time business applications
  • With real time integrated analytics
  • Delivered on any device in real time (securely anywhere in the world)

Of course you need HANA for this. But I think the real message for the partners here is that SAP needs them to deliver applications that leverage HANA. This makes Dr. Bhoudary’s comment about SAP’s tolerance to IP sharing even more relevant beyond the concept of building out industry solutions. I’ve said it before and I’ll say it again (and again and again if necessary)…Without this way of thinking, without the development of applications leveraging its technology, HANA is simply an elegant technical solution in search of a problem. And as Steve Lucas said, “No one wakes up in the morning and says, ‘I really want to install HANA.’ They wake up with problems to solve…. Partners make it real.”

 

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

SAP HANA Enterprise Cloud: Speed, Power and the Benefits of Cloud Delivered Faster

On May 7, 2013 SAP announced SAP HANA Enterprise Cloud. As the name implies, it is a cloud-based service that allows an organization to move existing (or new) implementations of the SAP Business Suite and SAP NetWeaver Business Warehouse, powered by HANA, off their own servers and into SAP’s massive data centers. Why would an enterprise want to do this? The short answer: Speed, power and the benefits of cloud computing without the disruption of replacing existing on-premise solutions. Speed and power come from HANA, adding visibility and agility to the business by enabling decisions to be made in real-time with volumes of data that were inconceivable just a short time ago. Cloud computing lowers cost and adds elasticity, allowing capacity to stretch as your business and your need for data grows.

This announcement builds on the progress SAP has made in bringing HANA to market, first with analytics and then applications powered by HANA, including both the Business Suite and Business One. Because HANA is essentially enabling technology and it is technologists that deliver the message, the significance and potential for business value is difficult to convey. This newest announcement is focused on the cloud, but without first understanding the power and potential of HANA itself, it loses its punch.  So let’s backtrack a bit and highlight what HANA brings to the party.

Speed

SAP HANA is the brainchild of SAP founder Hasso Plattner and is often referred to as Dr. Vishal Sikka’s “little girl.” Professor Plattner is Chairperson of the Supervisory Board of SAP AG and Dr. Sikka is Member of the Executive Board of SAP AG, Technology and Innovation. Both men are brilliant technologists. They speak quite eloquently about the possibilities created by this breakthrough technology, but often that eloquence is lost on business executives. The non-technical businessperson cares little about row versus column processing, in-memory databases, massively parallel processor arrays (MPPAs) or multi-threading.

However, they do care about speeding up processes like Material Requirements Planning (MRP) in a manufacturing organization or forecasting demand to optimize restocking the shelves in a retail environment. These and other “batch” processes are the Achilles heel of most ERP systems. Even as hardware innovation continues to accelerate, because they are “batch” and not real-time, they are run overnight or over the weekend. Between “runs” things change and therefore decisions get made with something less than a full and accurate picture of the world.

Benchmarks from early projects have proven that HANA can reduce these run times from hours to minutes, or even seconds, without constraining the amount of data processed. In fact doors are opening to bringing in volumes of data that were previously inconceivable. However, having been constrained for so many years, it is often difficult to look beyond current real and perceived constraints and understand the possibilities. While a business executive might not really care how this is accomplished, understanding some of the concepts to a certain extent might help business executives and their IT staffs see the possibilities. Without that vision, businesses will never make good use of the technology.

Parallelism versus multi-threading is one of those concepts. Most computers today appear to be able to do many things all at once. After all, you have multiple users logging into ERP and CRM and other applications, and you can record an inventory transaction at the same time you are entering a new customer quote or matching invoices to cash receipts, right? Not really.

A processor in a computer can really only do one thing at a time. But it breaks each of those transactions down into minute elements and strings them together into a “thread.” If the processor has 3 tasks to do, it does one element from one thread, then an element from the second thread, then one from the third before it cycles back and picks up the second element of the first thread. Because these elements are so small and this is happening so quickly, it appears as if it is doing all three things simultaneously, when in fact it is doing only one thing at a time. Think of it like going through a turn-style. Only one person fits through at a time.

Going massively parallel allows you to throw a large number of processors (or separate computers) at a task (or multiple tasks) to perform a set of coordinated computations in parallel, like adding hundreds or thousands of turn-styles. In order to do this, you might have to modify or even redesign the subway station or the football field where the turnstyles function, so it is not as simple as it might appear on the surface. But the net effect is to increase the throughput by several orders of magnitude. Yes work needs to be done to the application before it can take advantage of the power of HANA, but the potential for adding throughput, and therefore speed, is nothing short of amazing.

Of course this is an over-simplification, but hopefully it helps the non-technical business person see the vision of the kinds of massive volumes of data and computations that can be handled quickly and efficiently with HANA. One goal of SAP HANA is to eliminate the need for “batch” processing.  It reached this goal by increasing the speed at which computations can be completed. According to Prof. Plattner, “There is no batch any more. After 40 years of trying to kill it, batch is now a monster of the past. We can do this now.”

Power

While speed is great, speed for the sake of speed alone adds little business value. What is more important is the ability to make more real time decisions.

While computers and enterprise applications have opened new doors to new possibilities over the past several decades, most of us have also become accustomed to being constrained largely because our ability to generate and collect data has far exceeded our ability to process it effectively for decision-making. We need to break through those constraints in order to create the vision of possibilities:

  • We run MRP weekly. We plan and schedule assuming infinite capacity. What if we could run a full ERP the moment a new big order came in to see how it would impact the finite capacity throughout the enterprise?
  • We forecast demand by product line, not individual products, or by region, not by customer. What if, instead we could forecast by product for each customer by individual region?
  • We put a plan together to replenish shelves in a retail store mid-day based on sales last week or last month or even last year. What if we could re-plan at noon based on sales that same morning?
  • We analyze the performance of trade promotions once the program is completed. What if we could see the impact on profitability in real-time throughout the life cycle of the promotion?

Overcoming these perceived constraints requires a new way of thinking. At SAP, that new way is called “design thinking.” This concept was not invented by SAP, and SAP is by no means the only company that is doing it. But SAP has certainly embraced it fully. Virtually every employee directly involved with customers and/or products has been trained.

Design thinking is an important concept in unlocking the power of HANA. The SAP Services organization is engaged to conduct a comprehensive assessment, including a design thinking brainstorm session. The goal is to determine which solutions will have the highest performance impact as a result of moving to SAP HANA Enterprise Cloud.

Moving to the Cloud

This brings us to the real meat of the announcement: managed services delivered via the cloud. Perhaps the best way to describe SAP HANA Enterprise Cloud services is to point out what they are not:

  • This is not an option for companies to run applications powered by HANA in their own private clouds. It is really a private cloud for the customer managed by SAP. This was a purposeful decision on SAP’s part since the objective is to make the solution truly “elastic.” While this term may be common in technology circles, it is less so in the business community. Essentially, it means the customer is never constrained by hardware limitations. Data center configurations will expand (transparently to the customer) as more computing power is required.
  • This is not Software as a Service (SaaS). Customers will bring their own licenses to the party. There will be no multi-tenancy (multiple companies sharing a single instance of the software). Right now the offering includes all of the SAP Business Suite except for SRM (which has not yet moved to HANA), and/or SAP NetWeaver Business Warehouse, any or all of which must be powered by HANA. But SAP also welcomes other applications that might be developed using the HANA platform or existing applications that will first need to undergo a transformation whereby they will be powered by HANA.
  • This is not a public cloud like Amazon Elastic Cloud Compute (EC2) where any and all different types of applications can run. This is an environment specifically for HANA-powered applications.

These are managed services, where customers outsource day-to-day responsibilities for managing some segment of their solution to SAP. As part of the ramp-up process for any prospect or customer, the SAP Services organization will likely perform a comprehensive assessment, delivering advisory services to determine which solutions will have the highest impact on performance – “likely” because this is not a mandatory step. SAP pitches a design thinking session and this generally results in at least one project and may result in a whole bevy of projects or a sustained rollout.

Once a project, or projects are defined, SAP Services provides migration and onboarding solutions. For an existing SAP customer this might include bringing the application up to the latest release. Remember an application can’t just be dropped onto the HANA platform. SAP has spent a lot of time and effort “powering” the Business Suite with HANA. The fastest way to take advantage of this will be to come up to the latest release.

The ease or difficulty of this upgrade (and migration) will largely depend on how far behind the customer is and how customized its solution is, and therefore the range of difficulty will be quite broad. The prime candidates for SAP HANA Enterprise Cloud, at least initially, will be large enterprise customers, and they are most likely to have customized the application extensively. Small to midsize enterprises (SMEs) and very new large enterprise customers are less likely to require extensive customization because configuration options and the ability to tailor without programming have evolved dramatically over the past several years. But more mature implementations will probably need to overcome this hurdle.

If this, or other hurdles can be overcome, then the benefits of moving to the cloud can be very significant. The benefits are largely based on the elasticity noted above and cost related factors. The customer should never have to wait for new hardware to be evaluated, selected, delivered and configured – which is exactly what would happened if they continued to operate from their own data centers.

Mint Jutras research finds that cost and upgrade factors are perceived as the most important benefits of a SaaS offering (Figure 1). Given the tendency for many to equate cloud and SaaS (even though they are different) there is no reason why we can’t extrapolate these perceptions to this offering. Survey respondents were presented with five general categories of benefits of SaaS and asked to sequence them in order of priority (with 5 being the highest).  The numbers shown in Figure 1 (the mean average response) denote the relative order of importance.

Figure 1: Relative Importance of Benefits of SaaS

  • Cost factors: 3.59
  • Upgrade issues: 3.09
  • Support of distributed environments: 2.90
  • No hardware purchase/maintenance required: 2.75
  • Less IT expertise and staff required: 2.67

Source: Mint Jutras Understanding SaaS

While the upgrade factors can be directly applied in terms of the hardware, they will be a little different in terms of SaaS versus cloud services that are not based on a multi-tenant model. Cost factors are also a bit different. Customers will not experience savings in terms of software licenses with the “bring your own license” model. However, there should be some savings in trading hardware costs for services.

But the real cost factors come into play when you measure value. Recognize that you are making a quantum leap forward in terms of taking applications to an entirely different level in supporting real-time decision-making. Remember those “What if’s?” listed earlier? Without this type of option, most companies simply would not be able to afford this move, and even if they could, they might find it difficult, if not impossible, to keep up with the level of hardware and technology innovation being delivered today.

Key TakeAways

SAP HANA presents a whole new world of opportunity for speed and power, limited only by the customers’ ability to see the vision of what is now possible. It is most important to understand the potential and identify your own possibilities for innovation. These opportunities for innovation may be staring you in the face. Or you may have to apply some design thinking: dig deep into existing processes and identify those problems you have been living with for so long you might think they are unsolvable.

In the words of one early adopter: HANA solves problems that were deemed unsolvable in the past. As you identify these opportunities, the next question will be, “Can I afford the solution?” With the introduction of SAP HANA Enterprise Cloud services, the answer is far more likely to be a resounding, “Yes!” SAP HANA Enterprise Cloud also adds the ease of consumption of the cloud at an affordable incremental cost.

So once again, why would an enterprise want to do this? The short answer is also the best answer: Speed, power and the benefits of cloud computing.

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