Fiori

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

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

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