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.
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.
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?