Skip navigation

SAP TechEd 2015 in Las Vegas, held a couple of weeks ago, was a great show and successful as usual, with many thousands of attendees and hundreds of sessions. TechEd is the place to meet colleagues, hear news and upcoming developments from SAP, and get training on new products. TechEd is like getting an energy shot about everything-SAP, and leave it pumped up with excitement.

 

oXya has had great presence at TechEd, with a large team and successful booth. We had visitors from more than 1000 unique companies visiting our booth. In addition, I attended a few excellent sessions (see below), met with and had great discussions with a few SAP Mentors, and also had good discussions with SAP executives. In this blog post, I’m summarizing the highlights and key trainings from TechEd. We’ll expand on some of these in the coming weeks.

 

Key Trends in SAP TechEd Vegas

 

The main trend in TechEd was around HANA. No surprise there, and it’s not the first year that TechEd focuses on HANA. The difference from previous years is that HANA has become an increasingly central component of the SAP market, so naturally also a focus of TechEd. The event featured multiple “HANA Heroes”, companies that have migrated to or implemented HANA, with the help of SAP and companies such as oXya. See this short interview with Frederic de Belloy, President and co-founder of oXya, in which he shares some insights Frederic.pngabout customers’ adoption of HANA, and what led oXya’s decision to be acquired by HDS, earlier this year.

 

We featured one such customer Celio, the leading global men fashion retailer, in a webinar that we held a few weeks ago. For those of you who missed the webinar, here is a link to watch the full webinar, and also a link to the specific presentation from Celio’s CIO, Laurent Rousset, including their HANA project.

 

Another major focus at TechEd was around Internet of Things (IoT), and what SAP is trying to promote on this subject. The subject of IoT is related to something relatively new for SAP, which is analytics. SAP recently announced a new and impressive version of its SAP Predictive Analytics software, which I recommend everyone take a look at, to see what SAP can do with big data, data mining, and analytics. Hitachi Data Systems, our parent company, is also doing a lot around IoT and analytics – see this short interview with Dr. Greg Smith from HDS, which we recorded at TechEd, in which he explains what we do in this area.

 

As analytics was taking center stage due to SAP’s investments in this area, SAP also introduced three new products on Hybris. These are micro products for specific customer usages, for example a marketing tool that enables marketers to create highly personalized content, based on customer data. There is an entire, thriving market of small tools Greg_and_Parisa.pngconnected to Hybris, and this trend is expected to grow even further next year, as it is a key driver to leveraging SAP’s CRM.

 

SAP’s CRM tool hasn’t been great until now, and they’ve had lots of competition from excellent and strong tools, such as Microsoft’s CRM and SalesForce. SAP is trying to bring some new tools and services to the market, to better compete with the other CRM providers. Hybris and the marketplace around it are a major step in this direction. The Hybris marketplace includes a lot of micro products from SAP and various partners, and these services are consumed on a pay-per-use model (“as a service”).

 

Interesting Sessions at TechEd Vegas

 

As already mentioned above, we attended many great sessions at TechEd, and I would like to highlight three sessions that I round most interesting. This is also a good place to say “Thank You!” to SAP for a great event and for recording most of these sessions and providing them online – in the text below you’ll find links to video recordings of the first two of these three sessions, and at the bottom of the blog I'm attaching PDF versions of all three presentations (if anyone has a link to the third video recording, please let me know and I’ll add it as well).

 

The first session was TEC114, “Transition Paths to SAP S/4HANA”. I will expand on this session below, as this subject is something we’re discussing on a daily basis with our customers. For those of you who haven’t seen it, here’s a link to the video recording of the TEC114 session, as well as to the attached PDF version of the presentation.

 

The second session was SEC203, “Hacking and Protecting RFC Communication”, which focused on a highly sensitive security issue, a subject which is very important for customers, and also something that is easy to solve. The hacking demonstrations in this session focused for getting into SAP using the “ALEREMOTE” user, and were very interesting. The hackers demonstrated how they were able to change a system user, which is usually safe from external users, into a Dialog user with special programs, and get into the system with remote login. The session also had a discussion on how to protect RFC connections, and recommended reports that should be run in order to find out which RFCs are never used at all by users, and can therefore be disabled. In addition, it recommended reports to run authorization checks on RFCs, to find out which authorizations are most needed. The goal of all this is to avoid giving ALEREMOTE the unsecure role of SAP_ALL. Here’s a link to the video recording of the SEC203 session, and also attached is the presentation in PDF format.

 

The third session was BA262, “Monitor the Health of Your SAP BusinessObjects Business Intelligence Suite”. This session focused on a new BI support tool, to troubleshoot BO issues. This tool is a must have for all BO platforms: no real setup, transparent usage, and can be used directly on your production systems. This tool can generate reports with very interesting content (whereas EWA for BO is hard to configure, and provides too little info). In short, this new tool provides high value for BusinessObjects customers, and I highly recommend taking a look at the attached presentation, in PDF format, of this session (and a quick tip: "high" trace server level should never be let to 'on' on prod, it just kills performance).

 

Upgrade paths to S/4HANA

 

As already mentioned, there was a lot of focus at TechEd around S/4HANA, with many sessions and discussions around it. S/4HANA remains a grand statement from SAP, with some answers that SAP still needs to provide to the market. First, it is a new solution that still needs multiple components developed, probably in the coming year, for it to be a viable option for customers.

 

Furthermore, the shift from a current SAP version to S/4HANA is really opaque at this stage, and is unclear for customers. Customers are asking us many questions around how to migrate from their current SAP to S/4HANA, and SAP is not providing clear guidance and migration paths. Each time that SAP has come up with a new version, including with HANA, they have also offered very clear, straightforward guidance on how to perform the migration. However, with regards to S/4HANA, it’s the first time that I can remember in which SAP releases a product, and there is very little information about the migration process.

 

For this reason, the TEC114 session, on “Transition Paths to SAP S/4HANA” was very interesting, since it started answering some questions, though not all. What we learned in this session was about the 3 transition scenarios to S/4HANA, which you can see on slide 11 from the full presentation, on the right.

 

TEC114-slide11.png

The first scenario is a New Implementation. In this scenario, you are not reusing your ECC or R/3 instances, you just “burn” your old SAP environment, flip to a new page, and start with an entirely new SAP installation, from scratch. This approach allows you to redesign some of the business processes. Once you have adapted S/4HANA to your needs, then you can transfer the data from the old SAP system. When choosing this scenario, you can either choose to deploy S/4HANA on-premise, or SAP also offers customers to deploy on the SAP S/4HANA Public Cloud.

 

The challenge with this New Implementation scenario is that you cannot migrate any of your adapted business processes; you must ditch all the investments in business processes you have made over the years, and go with the SAP standard processes. I’ll detail more about this when describing the second scenario.

 

The second scenario is a System Conversion. You have an SAP system that you want to keep “as is”, and migrate it to S/4HANA. You also want to continue using the same business processes that you have deployed in your company over the years. To achieve that goal you take your current ECC system, migrate it to S/4HANA, and at the end of the migration you have your current business processes running on S/4HANA. My estimate is that most customers would want to use this migration scenario, meaning keep their current business processes.

 

With that in mind, there is one very important thing that customers must realize—the only available options for this migration scenario is on-premise, or through a 3rd party cloud. The SAP S/4HANA Cloud does not support this option, so you cannot use SAP S/4HANA Enterprise Cloud to achieve this scenario!

 

SAP is pushing customers to use their SAP Enterprise Cloud, but if you want to use the SAP Cloud, then you’ll have to go back to standard SAP processes. All the development that you have done in the last 5 or 10 (or more) years – you will have to get rid of all these, because SAP will not allow you to have specific development on their own cloud. So, if you want to take the System Conversion path, then you’ll have to do it on-premise, or on the oXya cloud, because we do does allow you to do this type of migration and keep all the investments and developments you have done over the years.

 

The third option is the Landscape Transformation. This is pretty much a new implementation, only the emphasis here is on consolidation. You take some different ERP systems that you have in different branches, locations, or geographies, and you migrate them to S/4HANA. You perform a selective migration – you keep your old ERP systems and continue to run some activities on it, but do a consolidation of Finance (for example) on S/4HANA.

 

With the Landscape Transformation scenario, SAP says you can use either the on-premise option or the S/4HANA Cloud, but again – the S/4HANA Cloud does not support any type of developments or business processes that are different from the SAP standard. So, if you want to leverage the S/4HANA Cloud option, then the consolidation must be in SAP standard, meaning you cannot use your own business processes that you have developed (similar to scenario #1). Once again, if you want to keep your own business processes, you can use either the on-premise option, or the oXya cloud.

 

Conclusion: out of the above three scenarios that SAP provides, my estimate is that most customers will want to keep their current business processes. As a result, they will choose the second scenario, System Conversion, in order to not lose all the investments they made on the business processes side. However, the System Conversion option is not supported by S/4HANA Enterprise Cloud, so the only options available to customers are an on-premise installation, or with a 3rd party cloud which supports this migration, such as the oXya cloud.

 

We should take into consideration that SAP are trying to convince their customers to move to the SAP HANA Cloud. Customers who didn’t yet thoroughly investigate the various migration options may not realize that if they indeed decide to go with the HANA Cloud option, they will be forced to get rid of all the specifically-tailored portions (modifications) that they have, and only use the SAP standard, as nothing but the standard is supported on the S/4HANA Cloud.

 

In the coming weeks, we will dedicate a specific blog to S/4HANA considerations and migration paths.

 

And of course, come to see us next week at SAP TechEd in Barcelona - we have a joint booth for Hitachi Data Systems and oXya.

 

---------------------

 

Melchior du Boullay is VP of Business Development and Americas Geo Manager at oXya, a Hitachi Data Systems company. oXya is a technical SAP consulting company, providing ongoing managed services (run management) for enterprises around the world. In addition, oXya helps customers running SAP with various projects, including upgrades and migrations, including to SAP HANA. Enterprises migrating to HANA are using oXya to perform the HANA migration for them, since they usually don’t have the in-house skillset and prior knowledge to perform that migration.

As every service provider knows, customers tell the best stories about your service. The best references that exist. When a happy customer tell their story, about how they benefited from your service, then that’s the best story there is. Much better than you speaking about your own service.Webinar_open_screen.png

 

Yesterday (Oct 14, 2015), I had the pleasure and honor to take part in a webinar that oXya held for customers, prospects and partners. I was specifically proud to open the webinar and introduce three of our distinguished customers – Celio, Smurfit Kappa Group, and Nextiraone – whose IT executives presented their SAP story, and how oXya helped them achieve their business goals.

 

These are not small companies. In fact, they are world leaders in their respective fields:

  • Celio is one of the world’s largest retailers for men’s fashion, with more than 1,100 stores across 60 countries around the globe.
  • Smurfit Kappa Group is a global leader for paper-based packaging, and Europe’s largest corrugated packaging company.
  • Nextiraone is a leading European IT Services firm, with operations across Europe.

 

Our business is all about our SAP customers. They are the ones for whom we work around the clock. We support them so they can achieve their business goals, grow and be successful. It is always heartwarming to hear complements for our service when we speak with a customer. All of you who provide services to customers, know what I mean. It is really special when a busy IT executive at a customer is willing to participate in a live webinar, invest the time and resources to develop a presentation, and provide a public reference to the entire world.

 

We are deeply grateful to Laurent Rousset, CIO of Celio; Tewfik Noumri, Director of Group SAP Competence Center at the Smurfit Kappa Group; and Flip Vandijck, Director of Global ERP Production at Nextiraone, for participating in our webinar, and for the warm words and compliments. We were honored to have them at our webinar, blushed at the compliments, and would continue to work hard and provide a great service to all of our customers around the world.

 

Celio.pngSmurfit-Kappa.pngNextiraone.png

 

Listen to their stories, as there are some very interesting things in there, about how they developed their SAP strategy, implemented HANA, and are using SAP to run huge, international businesses. Any SAP customer can probably take something from these stories.

 

Decision_Tree.png

In addition to the customer stories, our webinar presented a decision-making framework that we developed specifically for this webinar, based on nearly 20 years of servicing many hundreds of SAP customers. This framework provides a process for SAP customers who consider a migration to SAP HANA. The framework addresses the two main challenges that such HANA migration entails – the human experience & expertise gap with regards to HANA, and the high cost of infrastructure that is tied to HANA.

 

We take the listener step by step, and present some options and decision criteria to solve these challenges. This framework is also relevant for current SAP customers who are not thinking about a HANA migration, but would still like to improve the level of service they are getting from their SAP environment – for both the human factor and the infrastructure.

 

Take a look at our webinar – the three customer stories are presented right at the beginning of the webinar, one after the other, followed by the framework for HANA migration. I’d love to read your comments and questions here, in this blog, and will answer everyone and everything.

 

Also, come see us at the HDS/oXya booth at the upcoming two TechEd events, next week in Las Vegas, and in a few weeks (November 10-12) in Barcelona. We would love to meet with you face to face, hear about your SAP challenges and concerns, and discuss how oXya may be of service to you.

 

 

--------


Melchior du Boullay is VP of Business Development and Americas Geo Manager at oXya, a Hitachi Data Systems company. oXya is a technical SAP consulting company, providing ongoing managed services (run management) for enterprises around the world. In addition, oXya helps customers running SAP with various projects, including upgrades and migrations, including to SAP HANA. Enterprises migrating to HANA are using oXya to perform the HANA migration for them, since they usually don’t have the in-house skillset and prior knowledge to perform that migration.

HANA has been the hottest new technology from SAP in recent years. The innovative in-memory database, that is supposed to significantly accelerate the speed of applications, improve business processes, and positively affect the user experience, has been gaining significant interest from customers.

sap-hana.png

oXya, a Hitachi Data Systems company that provides enterprises with managed services for SAP, has significant experience with HANA migrations. To date, we have migrated to HANA about 30 of our 220 customers, or more than 10% of our customers. This is a much higher percentage than SAP’s official, overall HANA statistics, which stands at under 3% of SAP customers who have migrated to HANA. The number of SAP landscapes we have migrated is several times higher and well over 100, as we’ve migrated multiple landscapes for each customer.

 

oXya was one of the first companies in the world to perform HANA migrations. This blog’s goal is to help you, the SAP customer considering a migration to HANA, based on our extensive experience with SAP HANA. What are the main considerations you should look at, when considering a HANA migration? What may be some considerations against such a migration?

 

 

Cost: HANA is expensive

 

First discussion around any HANA migration is usually around cost, and especially the license cost. This is where you should ask yourself – am I ready to make this investment?

 

HANA is expensive. Of course, the discussion should be about HANA benefits and whether the migration is worth the ROI, but many customers don’t get to that stage; the investment itself is a barrier tall enough to prevent a migration, or delay the decision to some point in the future.

 

So what costs are involved with a migration to HANA?

 

1. HANA database cost. If you are currently running your SAP environment on an Oracle database (or MS-SQL, DB2 or any other), then you’re only paying annual fees for that database; the cost of purchasing the database itself had occurred in the past.

 

Migrating to HANA means you need to purchase an entirely new database, HANA. The initial database cost (Capex cost) will be at least a six-digit number in US dollars, and can easily go to a seven-digit number, depending on what you do at your SAP environment, which affects the size of the HANA appliance. We’ll get back to sizing later on, as that’s a critical point with HANA.

 

2. HANA annual maintenance fees. As a ballpark, your annual HANA license fees will be around 15% of what you’re paying to SAP for your other SAP licenses. So, for example, if you’re paying SAP one million dollars annually in maintenance fees, then you’ll pay around another 150,000 dollars every year, in HANA maintenance fees.

 

3. Cost of infrastructure for HANA. The prevalent method for installing HANA is on a dedicated appliance; the cost of that appliance depends on the size you purchase. HANA can also be installed as a Tailored Database Integration (TDI), where HANA is installed on larger, existing servers (compute, storage) in your datacenter, rather than as a separate appliance. In both cases, HANA requires significant hardware resources to run efficiently. The actual cost of hardware depends on the size of the HANA license.

 

4. HANA sizing. With HANA, you’re paying per gigabyte on the HANA appliance. This cost per GB applies to both the HANA license itself, and also to the hardware appliance. For example, if you’re running ECC on a 1TB appliance, then you will need to purchase a HANA license for a 1TB appliance. This means that the size of your SAP landscape and how your company use SAP on a daily basis have direct influence on your HANA cost.

 

Since you’ll be paying HANA fees per size, the correct sizing of your HANA appliance is very important. You don’t want to buy a HANA appliance that is too big, and pay for extra that you don’t use; you also don’t want to buy a HANA appliance that is too small, insufficient for your needs. Many companies are contracting oXya to perform the correct sizing for them, as correct sizing has a major effect on their cost, both appliance size and HANA license.

 

5. HANA Migration. One additional cost to consider is the cost of the migration project itself. Your in-house SAP team does not typically have experience to perform such migration projects. You need to hire the services of an expert company such as oXya, who has done many HANA migrations and has the knowledge, experience and best practices to perform the migration project for you.

 

 

HANA benefits: it’s not just about speed

 

HANA is not just about speed, and that’s important to understand. HANA is also about new functionality. There are many SAP functional consulting firms, who would help you in this area (oXya is not an SAP functional consulting firm). You should consider if you want to leverage that new functionality. If yes, then the new functionality is certainly a great reason to move to HANA.

 

However, if you’re only interested in increased speed for your current SAP applications, then HANA may not necessarily deliver on your expectations. While some people have attributed a 20x factor to HANA, with regards to increased speed, the truth is that you probably won’t get that. The speed of any process you have, like ERP or HR, can’t really go 20x faster for most of the major processes.

 

Don’t get me wrong – customer processes do run faster after a migration to HANA. In one representative case, for example, there was an improvement in the run time of a process from 15 hours to 8 hours. This is a great improvement, nearly 2x, yet the customer was disappointed. They expected much more from HANA. They thought the process will run in under an hour, meaning 10x faster, and that didn’t happen.denver_140821_0272_lo.jpg

So what is the challenge about processes and speed?

 

HANA is designed to run standard SAP processes, meaning processes that have been implemented and are running exactly like SAP designed them. In such a case, a given process can run significantly faster, even x10. This is one of the reasons why SAP keeps telling its customers to “go back to standard”; SAP wants customers to use the standard processes, those that SAP designed, so customers gain the maximum benefits from HANA.

 

However, the real world is quite different. Most SAP customers today have customized their SAP applications, with the help of functional consulting firms. I’d estimate that at least 90 percent of customers have modified the processes that SAP developed, in order to make the process better aligned with their specific business needs. However, these modifications affect the possible speed improvement with HANA, because these modified processes are not optimized for HANA. The result for most customers, from our experience, is that a migration to HANA brings improvements of “only” 1.5x to 2x in speed, and customers feel disappointed with that performance improvement.

 

The bottom line: if you’re planning a HANA migration just for the sake of performance, meaning making SAP faster, then that may not be a good enough reason for such migration. You’ll be paying a lot, and depending on the specific process—you may not get much improvement in speed, and certainly not what you’re hoping to get. I would therefore suggest that you plan your HANA migration carefully, taking into account additional benefits—and you won’t regret migrating to HANA!

 

 

POC is the way to go

 

Most of our customers are asking us to do a Proof of Concept (POC) for HANA, to see what such a migration will give them. We support this approach and encourage you to take the POC route, have a real test and see if the new functionality and improved speed meet your expectations.

 

POC has to be done with your real, live data, in order to know if the migration to HANA will meet your demands. Using your real, live data in a POC is a basic requirement, because that’s the only way you’ll know how your customization of SAP will be affected by the HANA migration. Using demo data from SAP is irrelevant, as it will not show you how the HANA migration will impact your specific SAP environment, especially in cases where functional customization was performed.

 

oXya is performing multiple POCs for multiple customers and prospects at any given moment. If you’d like more details, just contact us and we’ll discuss your specific requirements.

 

 

Considerations for delaying a migration to HANA

 

There are three main considerations that prevent customers from migrating to HANA. Furthermore, our experience shows that for most customers, a migration to HANA is not a definite “Yes” or “No” decision, but more a question of timing – when exactly to perform the migration, based on the following:

 

1. HANA cost and infrastructure refresh cycles: when I wrote about HANA costs at the beginning of this blog, I wrote mostly about the HANA license costs. Here, I’m referring specifically to the cost of hardware, and to refresh cycles for SAP infrastructure (servers and storage). A refresh cycle takes place every 3-4 years; customers depreciate their equipment over 3 years, but will often wait another (4th) year before buying new equipment.

 

Hence, a customer who has just ‘recently’ purchased new infrastructure (and ‘recently’ can be 1-2 years ago), and already spent a significant budget on that new SAP infrastructure, would usually not migrate to HANA at present time. They simply don’t have what to do with the existing (relatively new) infrastructure, and they won’t invest significant amounts in new infrastructure for SAP.

 

The exact same argument works the other way around. When a customer’s refresh cycle is coming up and the budget for new infrastructure is approved, that would be a good reason to move to HANA. The cost of moving to HANA may be a bit higher, compared to a regular, non-HANA infrastructure refresh, but that difference is easier to justify, due to the major infrastructure refresh.

 

2. Concerns regarding HANA maturity and migration path: we’re speaking with a huge and well-known retail brand about HANA, and they listed three concerns regarding this migration. The first concern was the already-mentioned cost; they told us the migration to HANA was too expensive for them. In addition to cost, their second concern was that HANA was not yet mature enough. They didn’t trust it for running the Business Suite on HANA, and for them to base their entire business on HANA.

 

Personally, I believe that HANA as a solution is mature, and for itself brings no risk to the organization. However, for that specific customer, there was another, third concern, which was a very complex, long and costly migration path to HANA. We analyzed the migration project and came to the conclusion that it would take about 18 months, from start to finish, since this customer has a very complex SAP environment, with many things that need to be taken into consideration. The bottom line is that this customer is right in not migrating to HANA at present, due to the complexity of the project, but this is not related to HANA maturity.

 

3. Issues with Product Availability Matrix. A third common reason, that prevents customers from migrating to HANA, has to do with product availability matrix. Some applications just can’t be migrated to HANA, and when such an application is mission-critical for a customer, that can prevent the entire migration project.

 

We have a customer that delays the migration to HANA, due to an application that is critical to their operations. That application is not from SAP, but it’s connected to the SAP system. The application’s version is not compatible with HANA, so HANA will not be able to read this application’s database. The customer also can’t upgrade the application, because that project is also very long and complex. The customer is planning to replace this application with another software package in about a year, to support a future migration to HANA.

 

The above example is relevant to many customers who have external, 3rd party products that are connected to SAP with interfaces. When these external products are critical to the business, yet can’t work with HANA, then such a scenario puts the entire HANA migration on hold. Before migrating to HANA, we must verify that all these products have a clear migration path to HANA, and they will continue to work with HANA.

 

 

Conclusions

 

As you read in this blog, a migration to HANA involves many considerations that need to be carefully analyzed and discussed. oXya, with about 600 SAP experts serving more than 220 enterprise customers worldwide, is having such discussions with customers on a daily basis.

 

If your organization is considering a HANA migration, feel free to reach out to us for consultation. You can ask questions or post comments here (I promise to answer), or contact your HDS rep about this.

 

 

 

About the author: Melchior du Boullay is VP of Business Development and Americas Geo Manager at oXya, a Hitachi Data Systems company. oXya is a technical SAP consulting company, providing ongoing managed services (run management) for enterprises around the world. In addition, oXya helps customers running SAP with various projects, including upgrades and migrations, including to SAP HANA. Enterprises migrating to HANA are using oXya to perform the HANA migration for them, since they usually don’t have the in-house skillset and prior knowledge to perform that migration.