SAP Business Suite

SAP S/4HANA: Simple, Fast, Different

What Does it Mean to the Business?

On February 3, 2015, SAP announced what it called its biggest product launch in the history of the company: SAP Business Suite 4 SAP HANA, or (thankfully) SAP S/4HANA for short, was touted as “the next-generation business suite to help customers run simple.” Indeed, “S” stands for simple; “4” is for 4th generation and in Information Technology (IT) circles, HANA speaks for itself. To interpret for those outside the world of IT, HANA is an advanced in-memory platform that is able to crunch through enormous volumes of data incredibly fast.

In combination these three factors hold enormous potential to change the way businesses are run. While the potential impact might seem intuitive to technologists, it is far less obvious to the typical business executive. And yet, in a world where the terms innovative, disruptive and transformative are all too often over-used and mis-used, SAP S/4HANA is disruptive innovation that can be used to simplify and transform your business. If you are interested in learning how, read on…

What is it?

SAP S/4HANA is a new product, which, like its predecessor (the SAP Business Suite) will include enterprise resource planning (ERP) and other complementary functions including:

  • Customer relationship management (CRM)
  • Supplier relationship management (SRM)
  • Supply chain management (SCM)
  • Product lifecycle management (PLM)
  • cloud functions such as SAP SuccessFactors (HCM) and its Ariba Network

Like the SAP Business Suite, it is designed for the large enterprise, and eventually will satisfy the requirements of the same 26 industries SAP has spent decades building out. This is a big and bold move for SAP. Given these similarities, some immediate questions come to mind. First of all, why develop a new product? After all, the SAP Business Suite could already run on SAP HANA. Secondly, is it really possible to replace over 400 million lines of code quickly enough or will a complete solution be decades in the making? To answer these questions we need to look at both the differences and the similarities.

At first glance, the differences that appear most obvious to the typical business user lay in the user experience and deployment models offered. Beyond the obvious is the new code line with a new and simplified data model, but more on that (and what it means to the user) later.

Choice of Deployment Models

The existing product was essentially an on-premise solution, although SAP has recently offered a cloud-based managed services option. The SAP HANA Enterprise Cloud (HEC) is a service that allows organizations to move existing (or new) implementations of the SAP Business Suite off their own servers and into SAP’s massive data centers where SAP would manage it as a single tenant solution in a private cloud. But this doesn’t carry the same benefits of lower cost and faster innovation possible with a multi-tenant software as a service (SaaS) solution.

With SAP S/4HANA comes a choice of deployment options. The On Premise Edition is available today while the Public Cloud Edition (multi-tenant SaaS) will be available soon (the first quarter of 2015), followed by the Managed Cloud Edition in Q2.

New and Improved User Experience

The user interface of the SAP Business Suite has long been a weak point, and also one of the hardest to “fix.” SAP is not alone in this dilemma. Many enterprise application solution providers struggle with this as expectations change over time, especially with the influence of consumer mobile devices. Users become dissatisfied with existing user interfaces but often getting them to change is like pulling teeth, for fear of the need to retrain users and because people (those actually using the software) get used to it and resist change.

SAP has actually been working on fixing this problem for more than two years. In the spring of 2013 it introduced SAP Fiori, a collection of 25 apps (initially) that surrounded 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, SAP Fiori had limited impact for two related reasons. First, the initial set of apps just changed the user interface (UI) and did not add any significant new functionality. And yet, they weren’t free. Customers balked at paying a fee for innovation they expected SAP to deliver as part of maintenance.

The second round of Fiori apps however began to add in new capabilities, but in spite of that, SAP responded to customer complaints and made them free (with maintenance). And today there are over 500 of them available.

The intended new user experience delivered with SAP S/4HANA is based entirely on SAP Fiori and SAP expects that over time more and more transactions will come from mobile devices, a very viable option with Fiori. New customers will engage with SAP S/4HANA through these apps right from the beginning. Those SAP Business Suite customers that migrate to SAP S/4HANA will have the option of continuing to use the traditional user interface, but of course Fiori apps won’t shore up this weakness unless they are really used. Hopefully, with the mindset of running a new product, customers will expect to engage differently and therefore take better advantage of the new experience and the new functions delivered through Fiori.

Beyond the Obvious

While either or both of these differences might be compelling, even together they don’t justify the time and effort involved in replacing 400 million lines of code to produce a new product. The real game changer here is the underlying technology that allowed SAP to reduce the data footprint by a factor of 10, increase throughput by a factor of 7 and make analytics and reporting orders of magnitude faster (SAP claims 1800 times faster). SAP’s goal was to achieve a zero response time.

However, many business executives running SAP solutions, as well as those of other vendors, might not perceive themselves as having a problem with response time and the size of their data footprint is hardly something that keeps them up at night. If you consider yourself in this category, what’s in it for you? The short answer is

  • Speed in getting at data and answering questions
  • The power of iterative questions, including immediate answers to new ones you didn’t even know you had until you started looking
  • The ability to base all decisions (strategic and operational) on as much detail, in as fine a level of granularity as you can imagine

Perhaps you don’t think you have a problem because you have adapted to the limitations of existing systems. Or you don’t know response time is slow because you never put your hands directly on the system. You might be accustomed to making decisions from data that is frozen in time (a snapshot) because it is not updated and available in real time. You may have waited so long for new queries and reporting that perhaps you stopped asking for them. You probably forecast sales at a summary level by region, assuming you can’t possibly analyze and predict sales at an individual customer level, by product and region, by sales rep. What if SAP S/4HANA could change all this?

Speed is obviously a key factor, but why should you care about reducing the data footprint? The answer lies in understanding why that footprint got so bloated in the first place. As your solution footprint has grown through the years, there is a very good chance you have introduced redundant data. If you started with ERP, then added CRM, both need customer data and product data. This redundant data needs to be synchronized. SAP estimates that 40% of the data load is the exchange of data between solutions.

In addition all enterprise solutions have traditionally 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. While the process is simple and effective (because you can gain access to these totals through a simple query), there were some drawbacks.

Not only is there more embedded code to maintain these totals, there is more contention within the data files. Let’s say a large enterprise has people all over the world entering sales orders. If totals are updated in real time, even though it might appear that all transactions are accessing and updating records in the files simultaneously, in reality, these updates happen one at a time. Before a transaction can update a record, it has to check to make sure no other transaction is trying to do the same. If the record is being accessed or updated by another transaction, it must wait for the record to be freed up. Of course it might take only seconds, but those seconds add up and response time slows.

This is also why 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.

And finally, keeping these totals up to date, whether in real-time or through batch runs, means you have to anticipate how and what you want to include in the totals. 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.

Removing these totals means no updates and no more contention. Dozens or even hundreds or thousands of transactions can be entered and stored, at the same time (literally, not just seemingly). This is what the technologists mean when they refer to “massively parallel processing (MPP).”

So SAP got rid of these totals and also the database indices. Database indices allow you to do key lookups. You can easily look up a customer or a product by customer number or part number because those numbers are keys, allowing the software to go (more) directly to a record without having to search through the entire file. But these indices are no longer required if you can search through even massive files and still get sub-second response.

In the end, SAP S/4HANA reduced the number of data tables from 110 to less than 10. And it also segregated out historical data from current data. By its very definition, historical data can’t be changed any more. That makes it easier to handle. So SAP segregated it and made it read-only, making it even easier to deal with the current data.

This flexibility and speed is the real value HANA brings to the business, along with improved, faster decision-making. However, to take full advantage of HANA, SAP S/4HANA must only run on HANA. Of course, this means customers will not have a choice of databases. Some industry observers are criticizing SAP for removing this as a choice. However, preserving that choice of database means SAP S/4HANA would be restricted to the least common denominator of functionality.

If SAP does not take full advantage of the benefits HANA brings, why create a new product? The SAP Business Suite already provides this freedom of choice, including the Business Suite on HANA. And SAP has promised to continue to develop and support the SAP Business Suite through 2025.

Some customers will be reluctant to spend the money on a new platform. Some will cite the skill levels of their current staffs. If customers want to remain on traditional databases, they should just stay on the SAP Business Suite, at least for now. If IT staffs have not upgraded their skill levels by 2025, they will have more problems to contend with than just limitations in response times. So maybe it is time for some “disruption.”

Disruptive Innovation

While technology industry observers love to talk about “disruptive technology,” many business executives think of disruption as a bad thing. Yet while certain types of disruption can indeed be bad, other types can also be good. Disruption that prevents you from delivering a product or service is obviously bad. Disruption that forces you to do things in a different, but better way can be very good.

Wikipedia defines disruptive innovation as “an innovation that helps create a new market and value network, and eventually disrupts an existing market and value network (over a few years or decades), displacing an earlier technology. The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect…”

SAP S/4HANA is indeed disruptive innovation, but in the good sense. It is a bold move for SAP. Obviously its customers cannot transform themselves overnight, but they don’t need to. SAP S/4HANA was designed to allow existing SAP Business Suite customers to migrate without the bad kind of disruption. And of course SAP can’t transform millions of lines of code overnight either.

While the SAP Business Suite was just that – a suite of products, eventually all this functionality will be embedded and delivered as a single product. SAP started with ERP, but will eventually add in functionality from CRM, SRM, SCM and PLM. It will start with those industries most likely to see the cloud as the next stop in their extended ERP journey, and then continue to broaden its industry reach. Of course for any company taking this big next step, as always, the devil is in the details. How will companies (both new customers and existing SAP customers) make the transition while SAP itself is still in transition? Will they be able to embrace the good kind of disruption while keeping the bad kind at bay?

Conclusion

The short answer is yes, but that too will be a journey. It will not happen overnight. The key to success is in allowing all the current and new solutions to coexist. While SAP S/4HANA only has 10 or so tables, those applications like CRM, SRM and SCM are expecting to find their share of the full-blown 110 tables. That’s okay.

SAP has also defined a virtual data model that can do a translation of sorts, mapping the old tables to the new data model. This is a key factor in facilitating the migration from SAP Business Suite to SAP S/4HANA without disruption. It not only allows these (currently additional) applications to interoperate with SAP S/4HANA, but also allows customers to continue running current reports that might rely on those old totals. So current and new customers both can ease into taking full advantage of the new capabilities. This is good since it will take companies awhile to realize they can now solve problems that are currently viewed as unsolvable.

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 , , , , , , , ,

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 , , , , , , , , , , ,