Big Data

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

With SAP HANA, will “Big Data” cease to exist?

I know that sounds like a strange question, particularly with all the hype today about big data. We’ve all been watching the volume of data grow and grow and grow. I’m sure you’ve heard as many statistics as I have thrown about. We’ve progressed from talking about gigabytes to terabytes to petabytes. So why do I think it might be going away?

Last Friday I attended one of SAP’s Startup Forums in the Boston area.  Dr. Sam Madden, who runs MIT’s CSAIL (Computer Science Artificial Intelligence Lab) presented the keynote for the event. While most might think the concept of big data is self-explanatory, Dr. Madden actually defined it as follows: Big data is data that is too big, too fast or too hard for existing systems and algorithms to handle. Big data, by Dr. Madden’s definition, might eventually go away. Not because there is less of it, but because we are better equipped to handle it.

SAP is certainly trying very hard to make this happen and its Startup Forums are manifestations of this effort. While this is the first of its kind in the Boston area, SAP has been holding these around the world for a while now. The format is interesting. Think of it as speed dating between really bright technologists and potential investors (including SAP Ventures and its $155 million venture fund). Picture 15 different startups in a room, each with five minutes to give their pitch on who they are and why their ideas are the next best things in the world of big data.

Why is this a match made in heaven for these guys (and yes, sorry, but every single one of them was male)? Because these brilliant minds come up with truly creative ideas and often need funding to get them (and their products and services) off the ground. SAP is looking for promising startups interested in developing solutions on top of the HANA platform. SAP doesn’t ask for money, code or intellectual property (IP).  It provides an SAP HANA test environment and development licenses, a development boot camp and technical support at no charge until the startup runs live on HANA. At the point when HANA is embedded in a product, SAP will begin to see some revenue.

Of the 15 presenting, some were already participating in the program; others were potential participants. Some made the HANA connection in their pitches; some did not. Dr. Madden suggested (and a panel of partners from technology investment companies from the area agreed), “Big data is over-hyped. It is a new name for something we have been doing for the last five years.” But he also acknowledged awareness of and access to new data as a result of the convergence of some major trends. We have the digitization of data. We’re collecting more because of the emergence of inexpensive sensors, access to cheap computing and storage and an increasingly connected world.

While it might be over-hyped, big data is not going away any time soon. There is still plenty of opportunity based on current solutions’ inability to handle the volume of data that already exists and is emerging from these trends. That’s probably a good thing for SAP and other vendors jumping on the in-memory and big data bandwagon. Right now SAP HANA’s value proposition needs big data. But do customers and prospects see that? And do they see HANA as the solution?

It is clear that those bright technologists presenting their ideas recognize this opportunity and HANA’s potential. As do the 170 live customers of HANA and the other 40-50 that have HANA projects underway. But this is still a very small sample of the 232,000 SAP customers worldwide, 80% of which are small to medium size enterprises (SMEs). Does the typical SAP customer (or prospect) understand what HANA can do for them? The answer isn’t just, “No.” The real answer is, “Hell no!”

SAP’s single biggest challenge in bringing HANA to market is not in developing the technology, but in describing it in a way that helps average business people understand what it can do for them. So far SAP has largely described it as an elegant technical solution in search of a problem. It also suffers from having initially described HANA as an in memory alternative to a traditional database. Dennis Howlett has summed it up the best of any I have seen so far in saying,

HANA is much more than that. While it might have started out as a poorly thought out (Oracle competitive) database play, it is a development environment that is providing ISVs with extraordinary opportunities to rethink business processes as well as providing the real time platform for both analytics and the transactional systems.”

But the average enterprise, particular an SME isn’t looking for a development environment.  This explains why HANA has been most successful in large enterprises where you have large IT staffs with big budgets and lots of problems to solve. But that is not how the vast majority of businesses spend their budgets, particularly SMEs. They are looking for a solution to a problem, but they don’t want to develop a solution.

The typical SME won’t develop a HANA solution. It will seek a solution developed on HANA. This is why the SAP Startup Forum is so important- to provide solutions to all those potential problems. Lots of problems, across lots of industries will require lots of solutions.

In the meantime SAP is also making its ERP solutions available on HANA thereby providing some important differentiation in a market where in some ways traditional ERP has become viewed as a commodity. But HANA will not differentiate SAP’s ERP solutions until or unless business leaders understand what HANA can do for them. ERP will run faster, but unless speed is a barrier to doing business, the business won’t pay much (if anything) to make it faster.

Businesses won’t pay to make life in general better. But they will pay to solve a particular problem or overcome a particular challenge. The challenge SAP faces is first in helping those business leaders identify those problems and secondly to convince them the problem is indeed solvable.

For those of you in my generation, think back to the phone you had in your childhood. For me it was a rotary-dial, three party line. Our biggest problem was calling a neighbor who shared our party line. If you had told us we could have a phone that would allow us to snap a picture and instantly send it to someone, not across town, but halfway around the world, we wouldn’t necessarily have jumped at the chance. First of all, we probably wouldn’t have believed you. Secondly, we wouldn’t have perceived the need to do it.  We just didn’t think like that.

It took us many years and many generations of technology to get from that rotary dial three party line to today’s smart phones and networks, with all the inherent capabilities. Something tells me it won’t take us 50 years before business leaders start demanding what HANA has to offer, but we’re not there yet. In the meantime, it is safe to say big data is here to stay.

 

Tagged , , , , , , , , , ,

SAP GRC Solutions Leverage HANA for Fraud Management

According to the 2012 Report to the Nations on Occupational Fraud and Abuse, published by the Association of Certified Fraud Examiners (ACFE), $3.5 trillion worth of fraud occurs every year. Industries such as insurance, public sector, banking, healthcare and utilities bear more than their share of this risk and often spend millions in their attempt to detect, investigate, analyze and prevent it, with varying degrees of success. Investigators are forced to wade through massive amounts of data, which potential perpetrators count on to shield them from detection and prosecution. To help companies face this challenge, last month SAP announced SAP Fraud Management, leveraging the power of its HANA platform. The goals:

  • reduce the cost and effort of investigation, by providing tools to better detect new and changing fraud behavioral patterns
  • redirect efforts away from false alarms in order to deter and possibly even prevent a fraudulent transaction from being completed
  • and of course… earlier detection by processing high volumes in quasi real-time

What Is It?

SAP Fraud Management is part of SAP’s Governance, Risk and Compliance (GRC) product portfolio, along with Process Control, Access Control, Risk Management and Global Trade Management. It is part tool (for the IT department) and part analytic application (for fraud investigators).

The potential for the solution was demonstrated at the SAP Insider GRC 2013 conference in Las Vegas using an example from the insurance industry. Michael Lortz, Sr. Director, Solution Marketing for the GRC portfolio of products played the role of an investigator tracking down a potentially fraudulent automobile insurance claim. A young policyholder had submitted a claim after an accident that had occurred between 1:00 and 5:00 AM. The detection engine flagged it as suspicious due to the combination of the age of the operator and the time of day the accident had occurred.

The first step Michael, as the investigator, took was to do a “network analysis” to look for the same set of circumstances in any other claims. Come to find out this young claimant, and two others involved in the accident were also participants in four other claims. What are the chances this kid had five different legitimate accidents involving the same people? Slim to none? Obviously the perpetrators of the fraud were counting on the sheer volume of claims processed to mask this. In fact, they were successful the second, third and fourth time. The fifth time around, with the help of some enabling technology, somebody noticed.

As a result, the transaction could be flagged as fraudulent before any payout on the claim was made. But more importantly, the engine that triggered this as a suspicious claim could be recalibrated to change the thresholds that trigger audits that would prevent, if not the second claim, at least the third and fourth. And through recalibration of the rules, the likelihood of any transaction flagged as suspicious turning out to be fraud is increased substantially. Tracking down “false alarms” is costly and unproductive. So the ability to reduce those “false positives” can represent a huge savings.

Part Application, Part Platform

So, is SAP Fraud Management an application or is it a set of tools from which a clever customer or an SAP partner can build an application? The answer is, “Yes.” It is part application and part tool and it relies on the HANA platform for some of its functionality. Of course, this example provides a compelling business case for the insurance industry. While this was automobile insurance, surely it could be tweaked for homeowners and other kinds of liability insurance. The net result is a complete, working application for this industry.

However, the processes of detection, investigation and deterrence are similar in managing any kind of fraud and can be pre-built into a framework:

  • Detection based on a set of rules
  • Analysis of a network of objects looking for similarities (participants in insurance claims in this instance, but just as easily dinner guests on an expense report, deductions on a tax return, etc.)
  • Combined with a timeline (in what period of time were all these claims filed?)
  • Documentation of decisions (e.g. not to pay a claim, to reject an expense or to conduct a tax audit)
  • Add deterrents and refine the process by recalibrating the rules for identifying possible fraud

But the team building SAP Fraud Management didn’t have to create all this from scratch. It also looks to HANA to speed the investigation with its ability to process and analyze massive volumes of data, seemingly in real time since there are no spinning disks to traverse. All data is stored in memory, speeding the process. Rules are defined natively in HANA, while the “calibrator” is a specific tool created for Fraud Management.

Similar scenarios could be constructed for public sectors and the detection of tax evasion or perhaps abuse of social services such as food stamps or disability claims. Or it could help private companies detect fraudulent expense reporting or questionable purchases. Given the ACFE estimates the average organization is at risk of losing up to 5% of its revenue to fraud, the potential payback is more than significant. It can be huge.

Chances are SAP will not speculatively develop these industry-specific versions themselves. It is more likely for some of its partners to develop them. Most notably, we might expect to see some of the larger management-consulting firms with large risk management practices develop these for industries they serve.

Conclusion and Recommendations

If your company is at risk for significant financial loss as a result of fraud, SAP Fraud Management is certainly worth a look. First quantify the risk and then assess the cost of your current efforts to contain and mitigate that risk. If you employ fraud investigators, you must have some measure of their success and chances are you measure the number of potential cases investigated, along with the number of real occurrences of fraud. The goal should not necessarily be to increase the number of cases of fraud detected, but to detect fraud more quickly and to minimize the number of cases you chase that lead to no fraud (fewer cases of false positives). SAP Fraud Management, powered by SAP HANA can help you stop chasing down rat holes. This will allow you to set thresholds of risk lower and investigate more cases that can be proven fraudulent. Ultimately the goal is to maximize the amount of fraud prevented.

 

Tagged , , , , , , , , ,

SAP Business Suite on HANA: Software that Reinvents Business. Reinvented.

Really? Yes, Really!

On January 10, 2013 SAP announced the availability of SAP Business Suite powered by SAP HANA, a new option for SAP Business Suite customers and an opportunity for SAP to deliver “transformative innovation without disruption.” That’s a mouthful, but one that has the employees at SAP super excited. While the announcement was well-received and the audience seemed to like what it heard, this group of IT influencers didn’t seem to exhibit that same level of excitement. But influencers can be a jaded bunch. All too often as you start to dig deeper you find the story just isn’t all that new or different. In this case I believe the tables will be turned. As influencers and SAP customers alike begin to explore and understand the new and very real possibilities, what first appeared to be just “interesting” will truly become exciting. And there is no limit to those opportunities to innovate.

The HANA Story: What It Means to Business

Part of the reluctance to “feel the excitement” might stem from the fact that we’ve been hearing about HANA for a few years now. Six years ago Hasso Plattner, cofounder of SAP and Chairman of its Supervisory Board, had a vision of what the system of the future would look like. That vision included:

  • All active data must be in memory. In Hasso’s words, he wanted to “get rid 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

But such a vision obviously took time to deliver, so for the first few years the world heard about this transformative technology, but couldn’t touch, feel or see it. In 2011 we started to see some results as HANA for analytics became a reality and pioneering companies began to see performance improvements previously unheard of in terms of speed and the ability to handle massive volumes of data.

In 2012 it became real as SAP released HANA as a platform for developers. But the vision was still one of powerful technology and much of the talk over the past six years has been presented in very technical terms. “Here is this super technology; let’s work together to find ways to use it.” That’s not necessarily how business executives and non-technical decision-makers think. Instead they think in terms of business problems. “I have this problem. How are you going to help me solve it?”

While the ability to “support live conversations” and efficiently “handle more users” might resonate with a business executive, these messages were often over-shadowed. Business executives don’t necessarily perceive the value of eliminating disks, simplifying data models or using math. They don’t know what MPP is or design thinking.

So now, with this announcement, 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.

It is in uncovering these types of solvable business problems that the excitement will build. As Dr. Vishal Sikka, member of the SAP Executive Board, Technology and Innovation said, “Now the software at the heart of thousands of the world’s best-run companies can work and think as fast as our imagination.” But many business executives simply don’t have the same kind of creative imagination as a Vishal Sikka or a Hasso Plattner.

SAP Business Suite might be reinvented on HANA but how does that help customers reinvent their businesses? The trick will be in unleashing their imaginations and helping them see the possibilities. Yet in its attempt to make the message universal and relevant at the highest levels of its customers’ organizations SAP often introduces a level of abstraction that is lost on its audience. So we need to translate some of these high level messages into something that might be a little more concrete.

Becoming a real-time business

SAP’s brochure says, “Becoming a real-time business requires managing daily business transactions of your core business processes in real time, such as finance, sales and production – and as well, to capture data from new sources like social media, mobile apps or machine sensors.” However, how many enterprises today have a stated goal of “becoming a real-time business?” They don’t. They have goals such as growing revenue or reducing costs to improve profits. They may or may not be able to connect the dots between those goals and collecting and analyzing data in real time.

For those dealing directly, or even one step removed from an actual consumer or consumer product, the value of data from social media and/or mobile apps might be intuitive. For these companies, their brand is of paramount importance and they take great risk in ignoring social media or opportunities to connect directly with potential customers through mobile devices. So adding this dimension to the decision-making process should be well-received once you get the customer to think in those terms.

For manufacturers of industrial products… not so much. The world is changing, but slowly. It is entirely possible for them to think “social” isn’t business; it is something someone does on their personal time. And mobile devices are what their kids use to text their friends, play games and listen to music. For those same manufacturers, machine sensors and automated data collection (ADC) devices may have been on shop floors for many years. Those sensors and devices may in fact have the ability to shut down a line of production before bad product is produced. But can the data be effectively analyzed in order to improve products and processes? It is very possible that vast quantities of collected data have been underutilized for years, for one simple reason – there is just too much of it. And because it is collected continuously and automatically, it is constantly in a state of flux.

That thought actually brings to mind a parallel in history that dates back to the 1970’s.

Will HANA Bring to IT what MRP brought to Manufacturing?

The business world hasn’t seen something with this kind of potential impact emerge on the market since the introduction of MRP in the 1970’s. Those outside of the world of manufacturing might not appreciate the real significance MRP had, but there are a lot of parallels between the potential for HANA and the automation of the planning process that MRP brought about.

In a nutshell, MRP (material requirements planning) 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. 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.

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 can experience an average of 10% to 20% reduction in inventory and similar improvements in complete and on-time delivery as a result of implementing MRP.

Now with HANA we’re introducing the potential to improve processes, not by 10% to 20% but by several orders of magnitude. But it also 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? That’s what Hasso envisions when he talks about “live conversations versus prefabricated briefing books.” But those used to making decisions from those briefing books need to be educated on the possibility of the live conversation.

And, oh, by the way, traditional MRP, a game changer in the 1970’s and 1980’s is in for a major transformation.  Early MRP, and even versions of MRP today took and still take a long time to run and need exclusive use of the data. So it is typically run overnight or over a weekend. Think of the possibilities if it could now run in minutes or even seconds. Is that possible? With HANA, yes.

“Transformative Innovation Without Disruption”

In his opening remarks Hasso introduced the concept of “transformative innovation without disruption.”  In fact innovation was a key driver for John Deere, the early adopter of HANA mentioned previously in the context of solving previously unsolvable problems. Derek Dyer, director, Global SAP Services, Deere and Company outlined three ways in which the company views HANA as a game changer:

  • Bringing new innovation to the business by solving problems deemed unsolvable in the past
  • Simplification of the IT stack while introducing the ability to deal with huge volumes of data
  • Better serving the business by providing real-time access to data for better decisions

John Deere was originally attracted to HANA based on the performance aspects of the platform. The “Wow!” it was seeking was speed. It has had some initial success with its early projects, but sees a new world with ERP now on HANA. It intends to transform itself from a manufacturing company to a solutions based business. An example: It plans to take data from sensors in equipment in the field, determine how the equipment is being used, under what conditions. Not only will the data be real-time, but it will also allow them to answer back to the customer with very personalized, specific answers, and also support better collaboration with suppliers, dealers and customers.

Seeking Innovation

John Deere and other early adopters can provide some examples and perhaps some motivation, but each company will have to discover its own possibilities for changing the game. This is where SAP’s reference to “design thinking” comes into play. It is a protocol for discovering new opportunities and for solving problems.  It starts out with defining the problem. Because these problems might, as John Deere points out, have been previously deemed unsolvable, this step might not be as simple as it sounds. But it is the first critical step in finding that “excitement.” It can also be the most difficult. SAP and its partners can help.

What about Disruption?

The very term “disruption” is a source of controversy these days. Many talk about “disruptive technology” and refer to it as a good thing. But there are different kinds of disruption. A new technology that disrupts the way you think about problems and processes can have a very positive influence. But when new software (for example a new release of ERP) disrupts your business because you can’t ship a product or support your customer, it is definitely a bad thing. Upgrades to software like the SAP Business Suite are often viewed as disruptive in the bad sense, rather than in a good way. This is the kind of disruption SAP is promising to avoid.

Customers can take advantage of the Business Suite on HANA without upgrading their existing Business Suite. Current reports and customizations are preserved, including integration with other applications. And even partial migrations are possible. And there is no forced march now or in the future. SAP remains committed to supporting the customer’s choice of databases, including database technology and vendors. So the choice is left to the customer.

Yes, there is a cost associated with moving the Business Suite to HANA, but pricing for the new database works similarly to pricing for other databases even though the customer will experience huge improvements in speed, including 10 to 1000 times faster analytics.

Key TakeAways

It is clear that a key value proposition for SAP HANA is speed, but the vast possibility for business innovation trumps the value gained for improved performance. But each SAP Business Suite customer will have to identify its own possibilities for innovation. For some these opportunities for innovation may be staring them in the face. Others will have to dig deep into existing processes and identify those problems they have been living with for so long that they might appear to be unsolvable. Once uncovered, ask the very real question, “Can I solve this problem today with HANA?”

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

Making Sense of SAP Business One with SAP HANA. Why Two Versions?

HANA, SAP’s in-memory computing engine has factored into SAP conversations for a couple of years now. Often HANA and in-memory computing are associated with “big data”, and hence associated with big companies. So the introduction of a HANA product for SAP Business One, SAP’s Enterprise Resource Planning (ERP) solution for small to midsize enterprises (SMEs) might not resonate immediately. And yet SAP has  not one, but two Business One products for SAP HANA:

  • SAP Business One Analytics, powered by SAP HANA
  • SAP Business One, version for SAP HANA

Given 79% of its customers are SMEs, SAP must know this segment of the ERP market, particularly the lower end, which is the target market for Business One, does not buy or implement technology for technology’s sake. There must be a perceived business value. Read on to discover when, why and how either or both of these offerings can bring value to the small business running Business One.

What are These Two Versions?

SAP Business One Analytics powered by SAP HANA is currently available while SAP Business One version for SAP HANA is still on the (future) horizon.

SAP Business One Analytics powered by SAP HANA

Back in June, SAP Business One Analytics powered by SAP HANA was in what SAP calls its “ramp up” phase.  This phase sits between the beta version and generally available (GA). During this stage, the software is delivered to a limited number of customers. Once a significant number of those customers have gone live, the product exits ramp up and becomes generally available. Currently there are 24 live customers, with 20 additional implementations underway. SAP originally expected the product to become GA in the fourth quarter of 2012 but ramp up went exceptionally well and GA actually occurred in July.

Analytics for SAP Business One includes predefined content (reports and dashboards) and provides interactive analysis based on an online analytical processing (OLAP) data model (also predefined). You can also create your own ad hoc reports using Crystal Reports. Enterprise search is also provided, allowing structured and unstructured free text search. Think of it as a Google search that crosses the boundary between your enterprise applications and the public domain of the Internet.

Customers running SAP Business One Analytics powered by SAP HANA continue to run the (transactional) ERP solution on their existing Windows servers using the Microsoft SQL database. The Analytics will run on a separate appliance, a Linux-based server where the SAP HANA database will also reside. Pricing will vary based on the actual configuration of the hardware and SAP does have a special pricing model for the SAP SME HANA products, but there will be an investment required. But before you assume that level of investment is out of your reach, talk with the SAP Business One partner that supports you. SAP has gone to great lengths to keep the price tag within reach for the SME.

SAP Business One version for SAP HANA

The second product, which went into ramp up in late September 2012, is SAP Business One, version for SAP HANA. A beta version was demonstrated during SAPPHIRENOW in Orlando on May 16, 2012, also demonstrating that SAP HANA is not just for the big guys. It is expected to be generally available late 2013. Think of this as SAP Business One with “HANA inside.”

This version will allow both the transactional and analytical processing to be run on the same server, both of which will be super-charged for speed.  While normally associated with “big data,” HANA is as much about speed as it is big data. And with speed, it is normal to add more and more data, reaching beyond that which is normally stored in enterprise applications. Think about the enormous potential of useful but unstructured data that is floating out there via the Internet.

While generally a database is optimized either for transaction processing (e.g. ERP) or analytics, can one solution be optimized for both? SAP says, “Yes, with SAP HANA.” However, even though both will run on one box, SAP Business One version for SAP HANA will not run on the box that customers run SAP Business One on today. So again, there will be some investment required; explore those costs with SAP and its partners. If you feel this would be a path you might take, there is no reason to delay your purchase of the Analytics powered by SAP HANA. You can take full advantage of the speed and functionality available today with SAP’s assurance that your investment will be protected.

Those that are satisfied with performance today or cannot justify the expenditure and transition to SAP Business One version for SAP HANA may choose to continue running SAP Business One on MSSQL. They will still have the option of purchasing the Analytics powered by HANA on a separate appliance.

Case in Point: Nashua Communications (Pty) Ltd

Nashua Communications is a good example of an SAP Business One customer that has been and will continue to evaluate different options presented by SAP. As a leading provider of converged enterprise network and communications solutions, the company is based in South Africa. It specializes in the design, implementation and support of converged networking and security solutions that use open, standards-based architecture to unify communications and business applications for a seamless collaboration experience. Nashua Communications is running live on SAP Business One Analytics powered by SAP HANA.

The company has a long history with SAP. Up until a few years ago it was part of Siemens and its global enterprise communication arm (Siemens Enterprise Communications PTY).  As part of the Siemens family, it had been using SAP R/3 for the prior 15 years. This changed when Siemens divested this group and it became part of the Nashua Group (within the Reunert Ltd Company).

According to Darren de Vries, Nashua Communication’s Chief Information Officer (CIO), “During our 15 years on SAP R/3 we had accumulated a lot of IP [intellectual property] around reporting. When we migrated to SAP Business One, this was one of our biggest challenges – 15 years of custom-written reports and queries were no longer there. The challenge had not so much to do with functionality – we had all we needed with some customization to SAP Business One and add-on software, but the standard SAP Business One reporting just couldn’t replace 15 years’ worth of time, effort and knowledge.

“In response to the challenge, we purchased the Business Objects (BOBJ) Business Intelligence (BI) tool and started implementing it. We were working with a South African partner of SAP’s that had BOBJ skills but not in conjunction with SAP Business One, so we found the project not the easiest; and progress was slower than expected.”

At this point SAP approached them directly about SAP HANA. “HANA was all about speed, in memory. But what appealed to us the most was that we could buy it off the shelf to work with SAP Business One right away. It was a no- brainer to our CFO. He said, ‘I want this. Go ahead.’”

When Nashua Communications signed on with SAP HANA it was still in the ramp-up phase and therefore the company was instrumental in identifying some problems, but these were resolved. Most had to do with the customizations and add-on functionality it had added to SAP Business One. This was a thorough test since Nashua Communications puts the solution through more paces than the typical SAP Business One customer. At the 300 user mark, if not the largest, it is at least one of the largest SAP Business One customers.

Because of the “newness” of the solution both to the market and to the company, Nashua Communication chose to roll it out first to a selected group of about 10 power users. Mr. de Vries goes on to say, “We are running now on a live environment and once we resolve the odd little glitch here and there, we are very keen to roll it out to the entire user base. We see enormous potential in terms of enterprise searching, speed and access to real-time data. We will empower each and every user as much as possible, but will keep report and query writing to a more technology literate group of people.”

So what about taking the next step to SAP Business One version for SAP HANA when it becomes available? Mr. de Vries states, “We see value in taking transactions to SAP HANA; performance is like night and day. If there is a cost to upgrade, we would have to come up with a business case to justify, just as we have done for the analytics side.

“For the Analytics powered by SAP HANA, the basis for cost justification was our fairly complex needs in terms of data and reporting. Quite frankly, we had struggled to get Business Objects up and running on Business One. The improved speed we experienced was a major factor. Equally important was access to live data rather than data that was 12 to 24 hours old.

“We also experienced a benefit that is quite unique to the South African market. Unlike the US where good telecommunication service is expected and people talk (rather loudly) about bad service, it is just the opposite in South Africa. Expectations are lower and people sing praises when good service exceeds expectations. We are hoping this access to live information will give us a competitive advantage to provide excellence in products and service.”

Key TakeAways

It is clear that a key value proposition for SAP HANA is speed, and even small to midsize enterprises can be faced with a growing challenge of making sense from and managing more and more data. Whether you consider this “big data” or not, the ability to apply analytics in real time without bogging down the transactional system of record can lead to a competitive advantage.

If you are an SME running SAP Business One now, or considering transitioning to this solution, don’t overlook the added strength of analytics powered by SAP HANA today. The enterprise search capabilities alone may suffice to justify making the transition. As SAP Business One version for SAP HANA becomes available later this year, this version, together with speed and the ability to better handle the growing data challenge should be a no-brainer for those just starting out. Existing customers will need to carefully review the business case for making the transition. For these customers, don’t assume SME means small data and don’t overlook the need for speed.

Tagged , , , , , , , , ,

Engagement vs Transactional Systems: Not a “from-to” especially for SME. SAP as an Example

I recently read Ray Wang’s Blog in the Harvard Business Review entitled “Moving from Transaction to Engagement” and something about it didn’t sit well with me. I wasn’t getting the “from – to” part. Recording transactions isn’t optional. Whatever tool you use to create your system of record (whether it is ERP or accounting applications or something else) is a necessary foundational tool. If you think tools that help you build relationships can replace transactional systems, then maybe you believed “eyeballs were everything” back in the dot-com boon and we all know how that story ended.

Since it troubled me I went back and read all the comments to Ray’s blog post and also a couple of pieces he referenced: Geoffrey Moore’s paper “Systems of Engagement and The Future of Enterprise IT: A Sea Change in Enterprise IT” and Dion Hinchcliffe’s “Moving Beyond Systems of Record to Systems of Engagement.” OK, I feel a little better now. But only a little.

I feel better because both Geoffrey Moore and Ray (in response to a comment) acknowledge that these transactional systems of record are necessary. And even Dion Hinchcliffe admits, “It’s safe to say that most firms would go out of business without the data within and automated capabilities of their systems of record.” But to say, they are all in maintenance mode, “ERP has hit its limit” and that “Transactional systems remain in a hard coded, rigid structured approach” ignore the change in how software is developed today and the real possibility of bringing better means of flexibility, engagement and communication to ERP. Yes, ERP must bring discipline and therefore must define data structures, but that doesn’t mean the application or implementation needs to be rigid.

I define ERP as an integrated suite of modules that form the transactional system of record for a business. So when we talk about transactions and systems of record, I assume we are largely talking about ERP. The trouble is, it has become harder and harder to tell where ERP ends and other applications begin. But that’s a good thing. It means software makers are providing added functionality and that ERP is seamlessly interacting with other applications. So why can’t we bring these characteristics of engagement systems (and maybe even experiential systems) to ERP? I’m not going to go down the route of “personal fulfillment” systems because we can’t lose sight of the fact that the purpose of the engagement is to generate transactions (because transactions mean revenue). I know I am over-simplifying but, I don’t think most executives want to discuss speed in the context of a time-space continuum and businesses can’t survive in a “feel good” environment where everyone gets a trophy for “engaging” regardless of whether revenue is flowing in.

SAP has gotten picked on a lot lately as a legacy application and as rigid, so let’s take SAP and its approach as an example of how transaction systems can be enhanced, not replaced by engagement systems. And let’s talk about it in a way that is not just for the large enterprise, because 78% (90,000) of SAP customers are small to midsize enterprises (SMEs). Customers are front and center of engagement, and to effectively engage you need to understand your customer. In order to understand your customer, you need data from a lot of different sources. Some of that data is structured and you are probably already sitting on a mountain of it from a variety of sources:

  • Your ERP system – what they bought, how much they paid, how well you performed in delivering product and collecting cash (all those pesky transactions).
  • Your support, contact or call center – including issues and resolution
  • Your Sales Force Automation solution – contacts, pipeline and quotes
  • Marketing Automation – how many times have you touched them?
  • Others might include document management, customer project management, engineering design and/or compliance specs, specific test results, etc.

SAP is approaching this by enhancing solutions from the outside in, rather than the inside out. What do I mean by that? I mean they are developing innovations SAP BusinessObjects Edge, business analytic applications and new dashboards and user interfaces that can be layered on any of their solutions, including those for SMEs like SAP Business All-in-One, SAP Business One and SAP Business ByDesign. That’s smart in two ways. First, they need only develop it once rather for each of their different ERP solutions. Secondly, by adding innovation in layers, they create the perfect environment for bringing data sources together from different applications. And in keeping these innovations on the “edge”, SAP can make them more “social” by tying in other sources of data, including “conversations” through chat and email, thereby supplying the “richer social orientation” of an engagement system. And once these new interfaces are placed on top of ERP, the user perceives them as a new and better ERP.

This also is the perfect opportunity to apply external business rules and event management, “smarter intelligence” that might otherwise be well beyond the reach of SMEs. Of course, looking beyond the conversations that might be shared between employees and customers, there is far more data out there about your customer than ever comes near your ERP and surrounding applications. There are Twitter streams and LinkedIn discussions and FaceBook pages. There are news feeds and stock watches. The list goes on and on. The trick is to put that data into the context of the data in ERP in order to put it into the context of your business.

And how you deliver it will be critical. Just constructing these focused dashboards is a good start. And perhaps good BI tools would be enough in the hands of a talented and well-staffed IT department, but SMEs won’t have that luxury. Part of “engagement” needs to be getting your employees, including business executives, to engage with the data that you have and that means engaging with applications -which is why it is more important for SAP to deliver business analytics as a configurable and ready to use application rather than just BI tools. But making these analytics accessible is also very important.

Business executives from large multi-billion dollar companies, down to the smallest startups want to be connected through mobile devices. And executives from smaller companies are just as likely to blur the lines between business hours and personal time, perhaps even more so because of the number of different hats they might wear in managing a small business. In our untethered world of mobile connectivity, we all become more tethered to work even in the “off hours.” And the older generation is now learning from younger generations and becoming more comfortable with specialized mobile consumer “apps.” In response, SAP is developing mobile apps and recognizes they must model consumer apps. That means they must be smaller in scope and more directly applicable to a particular function. No training required for the user interface and limited training required for the business process it is intended to perform.

SAP still has some decisions to make in making this type of mobility affordable to SMEs in a world increasingly moving away from corporate standards, producing a more “bring your own device” environment. But SAP has already delivered the SAP BusinessObjects Mobile app for iPad, in addition to the SAP BusinessObjects Explorer for iPad/iPhone , which is already one of the top downloaded apps for business with over 200,000 downloads from the Apple Apps store.

Of course no discussion of SAP would be complete today without mention of “in memory” but this is actually quite relevant in the context of both adding engagement characteristics to transactional systems and customer analytics. If you thought you were drowning in data before, once you open the door to capturing and channeling all these sources of public information, you will now be faced with a virtual tsunami of data. And make no mistake; this is not just a large enterprise problem. Once you open that door, you open the floodgates. So SMEs will need to deal with “big data” just as larger companies will. SAP is intending to bundle SAP HANA (its answer to big data) with SAP Business One for small companies, and SAP HANA will power SAP’s On Demand solutions, including By Design, but there might be a donut hole forming around Business All-in-One (BAiO). SAP HANA will be an option for both the Business Suite and BAiO and pricing has not yet been made public.

SAP is of course just one example, and I could have used other vendors as examples along the way. But SAP also has a very broad and deep footprint and has more irons in the innovation fire with more resources to bring to bear than your typical ERP solution provider. And SAP certainly touches a lot of SMEs (over 90,000).  But it also has a lot of history and a reputation of being rigid, in terms of both product and company. It hasn’t made the big splash about “Social” that Salesforce has recently. It’s been hard to miss Salesforce CEO Marc Benioff’s exhorting the virtues of the social enterprise.  But in the meantime SAP has been bringing more “engagement” to its transactional systems.

So the key takeaway here is that transactional systems can indeed take on some of the characteristics of an engagement system. While yes, they need to be structured, structured doesn’t necessarily mean rigid. I don’t think ERP has hit the wall – I think it still has a ways to go and many, including SAP still have the legs to take them there.

Disagree? Prove me wrong.

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