What’s New in the Annual Mint Jutras ERP Survey

I am excited to be preparing to launch my annual 2014 ERP survey. This will be my 8th and I’ve learned a lot through the years about how to ask the questions and how to best analyze the results. Since founding Mint Jutras in 2011 I have gradually shifted the timing of the survey, so that now (and in the future) it will be launched early in January, and I will use and reference the data throughout the year. As most of you know, I collect a massive amount of data. I try to be consistent with many of the questions from one survey to the next in order to make legitimate year over year comparisons, watching prior trends and spotting new ones. But each year I remove some questions that didn’t produce much insight (that’s how I learn) or that really don’t change much in one year. I do that to make room for something new.

It will be interesting to continue to watch trends, particularly around:

  • Buying cycles: Last year the percentage planning to purchase a new ERP within the next three years more than doubled from 24% to 47%, with another 15% undecided.
  • Deployment preferences: In the 18 months between the 2011 and 2013 surveys, the percentage of companies that would consider a traditional on-premise deployment dropped from 56% to 27%. Preference for both SaaS and hosted models increased.
  • ERP is reaching more users: On average 50% of employees actually use ERP today, including more executives. All executives have access to and regularly use ERP in 47% of companies, a far cry from just a few short years ago. We suspect the growing use of mobile devices has been and will continue to be a game-changer here.
  • Results measured since deploying ERP rose considerably with improvement percentages rising from the 5-7% range to double digits. These are improvements like cost reductions and improvements in on-time delivery, customer retention and inventory accuracy. “World Class” ERP implementations produced results in the 20-24% range. Was this an aberration last year or is new technology fostering better results?

What’s New This Year?

But what I am even more excited about is our new approach to capturing information about how the full spectrum of business applications, with ERP at the core, are implemented. Back when I started benchmarking ERP in 2006, I set out to quantify its usage. My first five annual surveys were done while I was at the Aberdeen Group where I came up with a formula for determining the percentage of ERP that was actually used. When I founded Mint Jutras I used what I had learned in those five years and modified that formula in order to get what I felt was a much more accurate result. But after eight years of this type of measurement, not only has this become old news, it is also harder to get an accurate read.

As I have been saying for several years now, the footprint of ERP has grown to the extent that it is becoming more and more difficult to determine where ERP ends and other applications begin. That is not only the case when covering, writing and talking about ERP, particularly as integration capabilities have improved, but for users as well. In prior blog posts this year I have discussed the relative advantages and disadvantages of “tightly integrated” versus “loosely coupled” applications. But this distinction is not intuitively obvious to the typical ERP user that takes our survey, particularly since typically less than 40% of respondents are in IT. Most are business users and may not have intimate knowledge of the purchase or the architecture of the product itself. They simply use ERP to run their businesses. And of course, that is primarily what we benchmark.

Modules versus Extensions: No longer the right question

In prior surveys I distinguished between ERP “modules” and “extensions” to ERP – those separate applications that might surround and complement it. I asked which modules were implemented (fully or partially) and then asked (separately) which additional applications were implemented. But as the footprint of ERP has grown, the overlap between these two lists also grew. While having both for any particular function might happen occasionally (e.g. a manufacturer might use supply chain planning functions of their ERP and also complement that with a separate “best of breed” solution), it would be the exception and not the norm. And yet, the number of instances where survey responses indicated they had both a module and an extension for the same function began to grow, casting a shadow of doubt on the validity of the responses. That told me it was getting too hard for the survey participants to answer the questions.

So this year I am changing it up with a different purpose in mind. This year, we will

  • Determine current state of implementations with a single list of functions, including traditional core functions of ERP (e.g. general ledger, accounts payable, accounts receivable, inventory control, order management, purchasing, etc.) and more advanced or “edge” functions (e.g. warehouse management, cash flow planning, BI and analytics, employee expense reporting, supplier collaboration, etc.) that might be a module or a separate application. The survey respondent will indicate whether it is (perceived as) part of ERP or not and, if separate, the level of integration.
  • Ask “what if?” Maybe this current state came about because of limited functionality and technology at the time of purchase. If the respondent were making the same decisions today, how would they go about it?
  • Ask “What next?” Given the state of their current implementation, what are most likely next steps? Add new components? Trade it all in for newer technology? Replace certain embedded functions? Eliminate separate applications now that ERP does more?
  • Have them choose up to five areas they are most likely to invest in next.

While this will tell us a lot, we’ll also drill a little deeper into plans for two areas, which happen to be among the hottest categories on the market today:

  • Human Capital Management (is it a fluke the big ERP vendors are buying these applications?)
  • Business Intelligence and Analytics (Is it time to take these tools out of the hands of IT and put them in the hands of the business user?)

We have also added a couple “Mobility” questions, along with one that will determine just how “usable” ERP data is.

If you are an ERP user, look for a link to the survey in the beginning of the year. We welcome your response.

If you are an ERP solution provider and think

  • The data we collect will be useful to you in making product roadmap or go-to-market decisions
  • Mint Jutras might be able to develop some good educational content for you with our distinctive “call to action”
  • You might like to benchmark your customers against our World Class

Please shoot me a message or contact Lisa Lincoln (

Lisa and I both wish everyone health and prosperity in the coming year!

Best Independent ERP Blog

Best Independent ERP Blog


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

ERP, The Next Generation: The Final Frontier? Part 1

Turning Your Business Into a Starship Enterprise

As the latest movie of the Star Trek franchise comes to a theater near you, let’s go out on a limb here and draw some parallels between Enterprise Resource Planning (ERP) and this entertainment phenomenon that began in 1966 by chronicling the interstellar adventures of the fictitious starship Enterprise. Like the USS Enterprise, whose five-year mission it was to explore new worlds and “to boldly go where no man has gone before,” early versions of ERP charted new territory for enterprise applications. It evolved from MRP (material requirements planning) to MRP II (manufacturing resource planning) and then boldly set out to conquer the “final frontier” of ERP, managing not a small piece of the enterprise, but the enterprise itself. And like the Star Trek franchise, after playing on both large and small screens for more than two decades, a “next generation” was born: faster, more technologically enabled and more in tune with the evolving needs of the galaxy.

This is the first post of a series on Next Generation ERP that will be unfolding over the next few weeks addressing the questions: Are you evolving with it as this next generation of ERP continues to evolve? Or are you stuck in the darkness of the 20th century?

The first several parts will be excerpts from a Mint Jutras paper of this same name, to be followed by individual posts about specific vendors. The inclusion or exclusion of a vendor in this series will be largely based on the relationship I have with the vendors and therefore how deeply and thoroughly I have been briefed on their solution(s). At this point I have no intention to insure that every major vendor is represented and the order in which they are presented has no particular significance. In fact I have already posted two of these:

But before you click on these links, read on for an introduction of our Star Trek themed series.

Star Trek: The Series, The Movie, The Software

Like the voyages of Star Trek that tested the nerves of the captain and crew of the USS Enterprise, ERP has often been an adventure, testing the nerves of CIOs and line of business executives at the helm of the enterprise. As the USS Enterprise explored the far reaches of the galaxy, it encountered alien cultures and new and different life forms. Traditional means of communication and familiar methods of interaction became ineffective. As businesses began routinely expanding beyond international boundaries, distances increased by orders of magnitude and they too experienced new cultures, new languages, new regulatory and reporting requirements and new ways of doing business.

The USS Enterprise had at its disposal amazing technology that allowed the starship to change course and even reverse direction immediately. It could travel at warp speed, using a hypothetical faster-than-light propulsion system. Star Trek was, and still is science fiction. In contrast, next generation, technology-enabled ERP solutions are very real. They help us cope with the accelerating pace of business, growing volumes of data and higher customer expectations. Yet, few can turn on a dime and unlike Star Trek’s USS Enterprise, ERP can’t operate at warp speed. Or can it? We are now entering a new phase of ERP’s evolution. New in-memory databases and technology are now dramatically speeding up run times and eliminating the need for batch processes.

But few are taking advantage of this new technology. The entire gamut of different generations of MRP and ERP are still in operation across the planet today, producing a wide range of value from very low to very high.  To many, modern technology-enabled solutions might still seem the stuff of science fiction when in fact they are in production environments, producing results that are nothing short of amazing. What generation of ERP are you running today? Have you explored the world of very real possibilities recently? If not, are you missing out and losing ground in terms of competitive advantage?

ERP solution providers: If you are interested in obtaining more information on this series and briefing us on how your solution is “next generation,” please contact Lisa Lincoln (

Tagged , , , , , , ,

Rumors of the Death of SAP Business ByDesign Greatly Exaggerated

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

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

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

Until now

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


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

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

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

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

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

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

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

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

Addressing Concerns

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

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

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

“SAP is no longer developing the product.”

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

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

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

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

See answer above.

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

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

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


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

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

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

Impressions from SAP Americas Partner Summit: Partners Make it Real

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

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

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

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

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

Leveraging the core business applications

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

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

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

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

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

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

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

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

Deliver in Mobile

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

Lead in the Cloud

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

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

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

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

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

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

Capitalize on Big Data (HANA, HANA, HANA)

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

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

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


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

JAR SYSTEMS: Poised for The Future With SAP Business One

If your small to medium size business (SMB) grew out of advances in technology, you would think you would naturally turn to technology to  help you manage and grow that business. Unfortunately when it comes to investing in Enterprise Resource Planning (ERP) to support growth and provide control, many SMBs are like the proverbially shoemaker: The shoemaker’s children have no shoes.

JAR Systems could have easily found itself in this type of situation. Founded in 2004, JAR Systems provides “mobile solutions for education and training” in the form of carts to store, secure and most importantly, charge mobile devices. But instead of struggling along with something less than a true enterprise-class solution, as so many SMBs do, JAR Systems viewed the cost of ERP not in terms of the cost of the software, but instead in the potential for missed opportunities. JAR Systems chose to take control of its business in 2011 with SAP Business One and hasn’t looked back since.

Seizing An Opportunity

No modern classroom today would be complete without its share of electronic devices. These devices come in a variety of shapes, sizes and capabilities and include full-size laptops, notebooks and tablets. All have steadily been making their way into classrooms for more than a decade now. With the emergence of these new technologies, schools face new challenges in managing devices and maximizing their availability. How will schools keep the software on devices fresh and refreshed? How will they make sure the batteries are fully charged? How will they store and secure them when they are not in use? These are all quite basic issues, but if not adequately addressed can seriously reduce the effectiveness of these devices as learning tools. And let’s face it: These learning tools don’t come cheap.

In 2004 JAR Systems seized the opportunity these challenges created and began offering carts that offer more than storage; they can be used for device management and “intelligent charging.” Device management can be scheduled and performed automatically at night while the devices are being charged. With intelligent charging:

  • Power sensors evaluate demand from mobile device adapters
  • Charging logic determines when and where power should be distributed automatically
  • Devices recharge in the quickest, most energy-efficient way possible

As a result of intelligent charging, schools save money (in energy bills) and maximize the time the devices are available for use. JAR Systems sells almost exclusively through partners and in 2011 it was at a crossroad of growth.

Taking a Step Back

Like many SMBs JAR Systems had invested first in a tool that would help them manage its pipeline, choosing This was hardly unusual in two ways. First, startups often worry more about where that next big order is coming from than about having a back office system to put it in once it is closed. Second the “software as a service” cloud delivery mechanism is appealing for those that have yet to invest in hardware and Information Technology (IT) infrastructure. is often referred to as a customer relationship management (CRM) solution, and indeed Axel Zimmermann, President of JAR Systems referred to it as such. JAR Systems was in fact using it as a window into forecast of demand. But while Salesforce does indeed manage contacts, sales activity and opportunities, it doesn’t extend very far into the relationship with the customer after the sale is made. As a result, it is very easy to throw a lot of data into the system, but it doesn’t require the same level of organization and discipline ERP requires.

Also, in JAR’s case, the forecasted orders were coming from partners, with several of them potentially competing for the same account. The result was a distorted view and an inflated forecast. And the company still didn’t have a good handle on the business.

So when JAR Systems decided to move forward with SAP Business One as its ERP, it also decided to step back from and use the CRM solution that is embedded within SAP Business One. Not only did that give them a deeper reach into the relationship with the customer, it also tied everything neatly together.

Flexible Control

While a stand-alone application like provides a great deal of flexibility in how data is structured and processes are defined, it doesn’t force structure and organization. It doesn’t need to. Some might refer to it as a system of record of prospect and customer engagement, but it does not maintain a system of record of transactions and therefore doesn’t require transactional integrity be maintained.

Because it is so flexible and the next order is of course the lifeblood of the company, many are tempted to throw everything but the kitchen sink into the system and that is exactly where JAR Systems found itself: With lots of data, but little data that was actually useful in terms of decision-making… and no transactional integrity.

A single solution combining ERP and CRM was the answer. Yes, it was a bit of a step backward to start over with CRM. But it also gave the company the opportunity to reorganize the data and add a level of control. This was especially important since all products are serialized, which adds another level of integrity that needed to be preserved, something you simply can’t accomplish with a stand-alone CRM solution.

It Takes a Village

This move to an integrated SAP Business One solution was not one to be taken lightly. And it was not something JAR Systems felt comfortable in tackling all by itself. All told there were four important parties involved:

MCS Business Technology is an independent, employee-owned consulting firm that partners with SAP in delivering SAP Business One and complementary services. JAR Systems turned to MCS for help with their implementation.  MCS Business Technology in turn partners with Boyum IT, also an SAP partner that is authorized to develop add-ons to Business One. One of the add-on modules is used by JAR Systems to tailor and customize the screens of Business One. One of the compelling factors for the particular add on is that it is certified by SAP and comes already integrated with Business One.

The third constituent was SAP itself. Two aspects were key, according to Mr. Zimmermann, “The technology world is changing so rapidly, we wanted to be assured that we could keep up. So far, upgrades have been painless. Business One is easier to update than my Windows machine.“ JAR recently upgraded to the latest release of Business One (9.0).

Mr. Zimmermann added, “Secondly, we looked long and hard at the roadmap while we were evaluating our options. We are looking for fast response time. We want to be able to ask questions that we can’t answer right now. We see the most immediate potential value in Business One, analytics powered by HANA. It is inspiring to hear the message and see the examples of what it can do. Of course we will buy Business One, powered by HANA later, as long as we can afford it. We want to use IT to revolutionize this business in ways previously not possible.”

For more information on these two different versions of Business One and HANA combined, see Making Sense Of SAP Business One With SAP HANA.

And last, but certainly not least, was JAR Systems itself.

JAR Systems had the insight and the vision to see that a small step backwards would yield a giant step forward over time. It’s ability to recognize the cost of lost opportunity as far more expensive than the cost of new software was both visionary and practical. There is no doubt that new technology will continue to bring about change in mobile solutions for education and training. While others might be apprehensive about the future, JAR Systems is poised to capitalize on that change to better serve its customers, while also comfortably positioned to leverage technology for its own business.

Tagged , , , , , ,

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

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

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


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


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

Loosely Coupled or Tightly Integrated Enterprise Applications? Why Should a CFO Care?

It seems lately I have been hearing a lot about “loosely coupled” business applications. It started about a year ago at Infor’s customer event (Inforum) and then continued at SAP’s SapphireNow. More recently, with SAP’s introduction of Financials OnDemand, I heard it again. Financials OnDemand is a derivative of SAP Business ByDesign, a cloud-based, tightly integrated suite (that some might call ERP). SAP pulled out the financials that were previously embedded in Business ByDesign so they could stand on their own and be “loosely coupled” to other applications.

But is this what its customers and prospects are looking for? That’s hard to say because it is very unlikely its typical prospect or customer really understands the intended “benefits” of loosely coupled.  In fact, when you start talking about “loosely coupled” to CFOs you are likely to produce that glazed look that says, “I don’t know what you’re talking about… and I don’t really care.” If you refer to “loosely coupled” in contrast to “tightly integrated” you might get a glimmer of understanding, but not an immediate acceptance of the concept.

CFOs might intuitively understand the value gained from tightly integrated applications, particularly in reference to an integrated suite of modules like ERP. After all, who wouldn’t want a complete solution, one where all the pieces just sort of fit and work together, with no integration effort required and no redundant data? While there might be some inherent value to having a loosely coupled solution, that value is not intuitively obvious to a CFO. Yet the opposite is true for both Infor’s CEO Charles Phillips and representatives of SAP, including former SuccessFactor CEO, now SAP’s chief “cloud” guy, Lars Dalgaard. They see enormous value in loosely coupled. As a result they either don’t see a need to explain it, or they have difficulty in explaining something they just intuitively “get.” Either way, the message is just not very clear to your typical financial executive.

So let me try to explain. The biggest reason “loosely coupled” might be of very significant value to a CFO is because things change. Markets change. Companies expand (or shrink). Software is enhanced. Technology innovation happens.  In fact, technology innovation often results from change but is also often the catalyst for change. Yet responding to change is hard.

Let me give you an example that should resonate with a CFO. Let’s say you are the CFO of a mid-size manufacturer who has helped your company expand over the past 10 years.  You implemented an ERP solution back when you were small and your accounting needs were rudimentary. You chose a solution for its strength in managing inventory and production. While you started out operating from a single location, you have expanded globally and now operate in 6 different countries around the world. While the financial modules of your ERP met your needs when you first implemented it, now you struggle with compliance and tax regulations, multiple legal entities, multiple currencies and consolidation. This is a very real scenario. Our latest Mint Jutras survey on ERP indicates 75% of companies today operate with more than one location. Even small companies (those with annual revenues less than $25 million) have an average of 2.6 locations and this average grows to 7.5 in the upper mid-market (revenues from $250 million to $1 billion).

You’d like to move to a newer, more feature-rich accounting solution, but your ERP is still satisfying the needs of manufacturing and since you are continuing to grow, you don’t want to disrupt the business by ripping it out and replacing it. The very thing that attracted you to your solution is now holding you back. Because it is tightly integrated, you can’t just replace a piece of the puzzle without replacing the whole thing.

To make matters worse, your older ERP solution is not really meeting your needs for customer relationship management (CRM). This is not surprising. While the footprint of ERP has been steadily expanding over the past 10 years, the needs of sales and service organizations were not front and center from the beginning. If these needs had been met with early versions of ERP, companies like would never have taken off like they have. Maybe you too are considering adding a stand-alone CRM to the mix. If so, SAP might be pitching its Customer OnDemand solution in addition to Financials OnDemand.

So is this building a case against tightly integrated, in favor of stand-alone solutions that might need to be integrated? Not necessarily. In a tightly integrated solution there is only one of anything – one chart of accounts, one customer master file, one item master, one supplier master, etc. But these master files are shared across different functions. Purchasing needs to access the supplier master to place a purchase order. But accounts payable also needs a supplier master in order to make a payment. Sales and order management need to maintain information in the customer master, but accounts receivable needs a customer master to apply cash receipts. Pull the accounting solution out and you still need the suppliers and customers. Does the new accounting solution have its own supplier and customer files? Does this mean maintaining two of each? Does the new CRM add yet another customer master? If so, how do you keep them in sync? Or maybe you don’t. But this adds all sorts of new wrinkles.

“Loosely coupled” applications could very well make your life easier. But what’s the difference between “loosely coupled” and what used to be called “best of breed?” This is where it gets harder to explain and I am not entirely convinced all vendors that claim to deliver it are talking about exactly the same thing. It took SAP several tries before I really saw the difference, and I live and breath this stuff. Your typical CFO doesn’t.

In trying to understand SAP’s definition of “loosely coupled” I described the scenario above to the solution marketing team for SAP’s cloud-based financials and asked how the combination of Financial OnDemand and Customer OnDemand would address this issue of redundancy. If each were sold separately (i.e. not delivered as the integrated suite of Business ByDesign) would the customer wind up with two different customer master files? SAP’s answer was no.

Here’s how it works: Think of the customer (master data) as a business object. An older ERP solution will build that customer master file (the business object) right into the solution. Instead, these OnDemand solutions treat the customer master as a separate business object that lives outside of the application. By doing this, both applications can point to, access and reference the same business object.

But what about maintenance? Instead of building the maintenance functions directly into each application, SAP treats that function as a separate function as well. Instead of building that directly into Financials OnDemand and Customer OnDemand, SAP builds it once and puts it in a “business process library” which both (and other) applications can use. The term “business process library” might be a bit confusing because most think of business processes in the context of processes like “order-to-cash” or “procure-to-pay” or “plan-source-make-deliver”. These are workflows that string together different functions. But in this case the business process is much more granular. It refers to the process of maintaining the customer master data.

So by loosely coupling these two applications, the customer still winds up with one customer master file. And both applications use the exact same functions to access and maintain it. These external business objects sort of plug into these applications.

This solves an important problem, but in our scenario, where we are replacing the accounting applications of an existing ERP solution, it is only half of the problem. If that existing ERP is still managing customer orders, it too needs to access the customer master file and it probably assumes the customer master file is the one that is delivered embedded in the ERP. So until or unless you do some potentially invasive surgery to the existing ERP, you are going to have to deal with some redundancy of data.

Of course if you replace that tightly integrated ERP solution with a newer or upgraded solution that has been assembled with loosely coupled external business objects, this problem goes away. In the meantime, SAP, and potentially other solution providers are beginning to re-architect their solutions to make this much easier. They are essentially performing this surgery and delivering applications that make better use of underlying supporting technology to make this happen. Remember the $6 million man and the bionic woman? They were still people, but with some of their “parts” significantly enhanced. Think of it as bionic ERP.

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

Is SAP’s Cloud Strategy Like the Blind Men and the Elephant?

As I watched a Twitter conversation recently discussing SAP’s cloud strategy, I was reminded of the old story of the blind men and the elephant. While there are different versions, the upshot of the story is that each blind man “sees” something different because each is only touching one part of the elephant. Without sharing their experiences and collaborating nobody gets the full picture.

Doug Henschen, executive editor of InformationWeek, sparked the discussion with his article SAP Clings To A Dated Cloud Apps Strategy. Doug writes, “As cloud vendors, NetSuite and Workday look toward larger companies, SAP courts small and midsize firms.” Doug was at the same event I attended last week, SAP’s SME Summit. So yes, the message being delivered by SAP at this event was one targeting SMEs (small to mid-size enterprises). His article mentions both SAP Business One which is available through on-premise and Software as a Service (SaaS) deployment models and SAP Business ByDesign, an exclusively SaaS offering.

However, two weeks prior to that, I also attended SapphireNow in Madrid. In a cloud strategy session there, I heard SAP Financials OnDemand, which is a derivative of SAP Business ByDesign and therefore an important element of SAP’s cloud strategy, was targeting medium to large enterprises. Does this mean the folks at SAP are not collaborating and instead are giving different and conflicting messages? I don’t think so. I think it means the same product can serve different markets and can be presented differently to different audiences.

Second question: Does this mean the target for SAP is different than the target for the likes of Workday, and NetSuite? Not necessarily. Some will argue that the “large enterprise” play for Financials OnDemand is limited to subsidiaries of large enterprises.  First of all, this a similar message conveyed by many solution providers citing “2 tier ERP strategies.” But often that is the very definition of a large enterprise: a collection of smaller business units or subsidiaries. Not only do these subsidiaries roll up to corporate financials, they often must deal with the same complexities as their corporate parents.  Some deal with those issues better than others.

So in many ways, all these solution providers are attacking the same market. SAP is just coming at it from a different direction. While the solution providers noted (all of which started out as SaaS vendors targeting small and/or midsize enterprises) have been coming up-market, SAP has been moving in the opposite direction.  SAP is best known for its presence in the largest of large enterprises and nobody would argue that market is quite saturated. Real growth potential lies in the small to midmarket space. Whether one direction is any easier or more difficult than the other, the challenges are definitely different.

In coming up market, these pure SaaS vendors need to add features and functions required by large multi-national enterprises. In coming down market, SAP needs to eliminate a combination of real and perceived complexity. Indeed back in 2007 SAP admitted it started by building Business ByDesign from scratch primarily to reduce that complexity.  And yet as smaller and smaller companies began operating globally, the complexities associated with multiple currencies, multiple languages, multiple legal entities, increased regulatory compliance requirements and global trade needed to be addressed even in smaller companies. The upstarts had the advantage of simpler solutions to build upon and SAP had the advantage of design teams that had been routinely addressing those needs for many years, particularly in terms of finance and accounting.

In his article, Doug even mentions that, “…CEO Aneel Bhusri said Workday’s Human Capital Management apps are already capable of handling the largest companies in the world, like Hewlett-Packard and DuPont, both of which recently signed enterprisewide deals with the company. Workday’s financial apps are currently suitable for use by midsized companies, Bhusri said, but by the end of next year — after investments in cloud capacity and app resiliency to sustain high-scale transaction processing — they’ll be ready for Fortune 1,000- or even Fortune 500-sized companies.“

That’s the market where SAP made its name and asserted its dominance.

But in determining strategy, here’s the big question: What will move to the cloud and what will remain on-premise (and is SAP’s strategy well aligned to that)? Many seem to think everything will steadily progress towards cloud-based and SaaS solutions, eventually replacing all on-premise solutions. I think it will take a very long time to get there. My latest survey on “Understanding SaaS” indicates that about 17% of business applications used today are SaaS-based and in 5 to 10 years that percentage will (just about) double, with 33% projected to be operating in a SaaS deployment model.

Is that because there is reluctance to accepting the SaaS model? No. It is because there are so many on-premise solutions that would have to be replaced. ERP and accounting solutions running large enterprises today might in fact be the least likely of these to be replaced, simply because of the cost and effort expended in initially getting them implemented. While that cost and effort has steadily decreased over the past 10 years, that doesn’t change the fact that these large enterprises spent a whole lot of time and money getting them up and running and the prospect of going through that again is not too appealing.

Yet installing a new cloud-based solution for a business unit or a subsidiary that is not currently fully supported by the corporate solution may indeed be very appealing. For a large enterprise with an existing SAP solution, Financials OnDemand or even the entire Business ByDesign solution may be a very good option for a subsidiary, business unit or remote operating location. Once a large enterprise has done this one or more times and the cloud-based solutions are feeding the corporate solution, perhaps it will pave the way for a transition to a 100% cloud solution in the future. If so, which cloud based solution do you think might make the transition the easiest? Do you think SAP might have thought of this too?

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