SAP HANA Reviews

We use SAP HANA for our BW system, which is the system we use for our BI tools and BI reports.

What's most valuable in SAP HANA is that it covers the business process systems of my company. The solution also helps because it makes almost everything automated. Another valuable feature of SAP HANA is that it can be integrated with third parties and other enhancements needed by the company.

What needs improvement in SAP HANA is its automation, in particular, it needs more enhancements in that area.

Right now, what I need is already covered by SAP HANA, so I have no additional features in mind for it.

I've been using SAP HANA for four years.

SAP HANA is a stable and reliable solution.

SAP HANA is a scalable solution.

The technical support for SAP HANA is good. On a scale of one to five, I'm rating SAP support five out of five.

The initial setup for SAP HANA isn't complex. It would depend on what you need, but it's easy because you just need to define the business process and blueprint, get approval from your business team and technical team, build the structures, get approval, then configure, assign, and get approval again so you can start working on SAP HANA.

The total time it takes to deploy SAP HANA would depend on the gathering of information, checking what prevails, arranging it correctly, getting the approval, then proceeding with the deployment. You should have a plan regarding the timing, the processes, the resource, the budget, etc., for the deployment of SAP HANA.

On a scale of one to five, I'm rating the implementation of SAP HANA as five out of five.

SAP HANA is more expensive than other solutions.

I'm working on data selection, upgrading database engines, and updating database versions. I'm the IT Application Manager, so I assist in those areas.

I'm working on the latest version of SAP HANA.

My company has an SLA contract with SAP for the maintenance of SAP HANA, which means that the SAP team will take care of the maintenance. You also have the option to cover the maintenance yourself if you have a team of SAP HANA consultants and seniors.

In my current organization, a total of five hundred people use SAP HANA.

I would recommend SAP HANA to others, particularly for business process needs. You need to make sure that the solution is already defined for your organization's business process. For example, if you're in the manufacturing industry, then SAP HANA should be defined for manufacturing. You shouldn't have to make many customizations to it. This is what you need to check first. SAP HANA should cover all and automate your business processes without needing a lot of customizations.

My rating for SAP HANA is nine out of ten.

My company is a customer of SAP.

The client is using the solution for supply chain management, and at the same time, our enterprise uses it to track the businesses' performance. The rest of our regions are going to be using SAP ECC. We are the first region to go with HANA. We were shortlisted to show them the roadmap and guide them. Supply chain management and tracking raw materials were areas of concern.

The IBP module was the most useful followed by the FI/CO and CNMM modules.

The product could be improved in several ways.

First, before carrying out a project with this environment size, a POC needs to be carried out, for which you would have access to various environments. And those environments are something that SAP should invest in and others should provide. That would be an improvement.

Second, some good amount of handholding, guidance, or other validation or certification from SAP at different levels.  

Third, access to tools for a longer period than the pre-defined trial version license. That's something that we can ask our friends from SAP to extend or make available in a different licensing model at zero cost.

I have three years of experience with the solution.

The solution is very stable. We would rate its stability as eight out of 10.

We would rate the scalability of the solution as eight-plus on a scale of one to 10.

The initial setup was pretty complex, considering the enormous amount of data they had from an Oracle ERP. Migration was an especially painful task, but we managed to sail through it thanks to the support of our customer. We delivered it within the timelines. We managed a few escalations. We worked with the customer. We had a weekly stand-up with the customer and various workshops and sessions to educate them and highlight the challenges. 

Implementation was completely in-house with a team of around 18 to 22 people and a couple of people from SAP, who looked at the overall program management level, providing guidance plus certifying that best practices were being followed and implemented. 

The deployment, moving from Oracle to SAP HANA, took around eight months

The customer took care of all the SAP license costs. Our scope was primarily implementation and migration support.

Oracle ERP had the flexibility, but it didn't have the functionality that the customer was looking for.

We would give the product an overall rating of nine out of 10.

We have an entirely SAP family, which makes it easy to manage and support. The customer opened its first, and we are doing multiple instances of SAP ECC implementations for the rest of the small countries in APAC, the Middle East, and Africa.

Around 175 to 250 people use the solution at every level of the customer's organization.

We will be providing maintenance for the next five years.

My advice would be to explore and play with the different systems available in the market. But, ultimately, look for a system with a brand, broad user usability, and support. For instance, my customer wanted to explore an open-source ERP. We persuaded him to go with SAP, primarily because they have the expertise. They adhere to the best policies. They offer support, etc. 

If you don't have all this, don't explore freebies. Go for a licensed version, recommended globally, and highly rated by Gartner or various research and consulting firms.

I was using the product for some research in technical drawings - in terms of making some drawings, the different parts, and the structure of the machinery. I don't know if it's available in the SAP HANA, however, there is a model for this to schedule the maintenance. The company wasn't using it. Sometimes the product furnishes a lot of insights, cultural insights that the company still is not ready to implement.

The solution offers advanced features that the company was struggling to implement. For example, in terms of parts, you can't implement a lot of structures of the machinery, however, you still need to use the codes. They're not related one to another, which makes them hard to find, typically. That means every time you need it to buy an entire assembly of parts, you need to know exactly which one you had. You have to use a drawing, a technical drawing, that specifies each code that you need. SAP saves you from asking to bring an entire assembly with a lot of parts. That's a powerful aspect that could help to reduce hours of work that are wasted in this way.

A documents preview could be helpful. Today we have a lot of documents, for example, in PDF formats, which we would like to preview. We'd even just like to click on an icon and have it open another tab. That way, I can see the document directly inside SAP HANA. In the company I was working with, we had a parallel system which meant we needed to go to SAP, see the code, see the drawing number, and then go to another system that is finished by Autodesk, and then find the drawing and open it. This is a lot of work.

I really would like to just have it inside this app. 

I'd like the product to have more mobile aspects. Many younger users want mobility and flexibility.

The solution can be expensive. In Brazil, many companies still do pretty much everything in Brazil, and, if they want to try a new solution, they want to try it at zero cost. Many, therefore, will look for open-source solutions before they even consider SAP.

I've used the solution over the last 12 months. 

It's very stable. Sometimes it gets a little slow, however, that might be a company issue. When it came to the internet the entire site wasn't that good. Sometimes you had too many people connecting and the company was using a lot of Google solutions. You noticed that when a lot of people are in virtual meetings, we would have internet connections affected.

I'm not sure about the scalability.

I don't know if you can use it in a Docker or if you can scale it in SQL and you can maintain the speed, or if you are talking about, for example, big data. The infrastructure of the company seemed to be weighed down, for example, when there were a lot of virtual meetings and it affected the internet. I can't speak to if this problem would also affect being able to scale the product.

I would describe technical support as good. It's always worked for me and therefore I have no complaints. 

I didn't handle the initial implementation. The company furnished all the equipment needed for me to work. They gave me the computer, which Red Hat was installed on. They just give me access and showed me where to access what I needed and where to put the ID and password. I didn't do anything.

Typically there are six people that are available for maintenance tasks. They're IT technicians.

SAP solutions are typically quite expensive.

I'm a partner and consultant. 

I'm not sure which version of the product I am on.

I'd advise new users that it's important to first find a solution that can understand the culture that's involved inside this solution. Sometimes people think that ERP software like SAP are magical things that you just install it and it makes life easier. It doesn't work like this. You need to have the culture, you have to have this knowledge. You need to understand how it works and how much it requires from you. It requires more than you think. It doesn't work like magic.

I'd rate the solution at a nine out of ten. It's very good, however, there's always room for improvement. 

I am currently using the latest version. But before that, before I jumped into the version, I used the initial version of HANA, as well. This initial version of HANA was not that great, it had a lot of bugs. But the latest version is very good. It's excellent.

I'm afraid that HANA is not a relational database, it's a column-level database just like Sybase IQ. Sybase is also an activity product, an SAP product. SAP bought Sybase in May 2010. So normal Sybase is RDBMS. Sybase has one more variant called Sybase IQ. That is not RDBMS, that is a column-level database. Normal Sybase is a whole-level database. That's a column-level database. So SAP HANA is based on this column-level architecture.

One more thing. The success of HANA primarily depends on the RAM and the storage. HANA became a success because the cost of the solar devices has fallen down substantially. I don't know about British Pounds, but in Indian Rupees, earlier in 2007, 2008, when I was working for Microsoft, one terabyte of a SAN device, used to cost around 22.5 LAK. I would say I would have had a 100,000. I think that's the nature. So one SAN device was costing 22 LAKs. The same SAN device, in 2013 and 2014, was costing around three LAKs. So the SAN device cost reduced by more than 200%.

Also, in parallel, the RAM cost also decreased, and the technology and the fastness of RAM increased. This impacted the primary condition for RDB and RDBMSs like Oracle, Sybase, SQL Server, and the like, that they need to support the foreign key relationship, where I have a few tables. For example, if I have five to six tables, suppose the first table is employment information. The second table is employee career details or his project, something like that.

Now, instead of populating the tables with the same information, the primary condition of RDBMS was to have a foreign key relationship between these two tables and reduce the redundancy. That was a primary condition, but in HANA, thanks to the cheap storage and high-speed RAM, I may not even bother to do a redundancy of data. I can combine all the tables and make a huge table. And as an entire table, whatever its size, I can pin the table in the RAM so that my access of information is not from the hard disk, but is directly from the memory, which is much, much, much faster. That is the beauty of HANA.

I'm still researching the features of HANA. In terms of memory, data access and data pitching, HANA has scored a victory, no doubt about that. But when I compare the non HANA architecture with SAP, ERP, the SAP ERP comes in two levels. SAP ECC, which is a non HANA based product, and SAP S/4HANA, which is a HANA-based product. If I compare these two, there are almost around 5,000 to 6,000 tables, which were merged together in HANA,  making it a robust architecture.

In earlier SAP we used to have fragmented, small-scale architecture. HANA is a robust architecture where one table itself is a behemoth quantity of many, many columns and a lot of redundant data. So my interest in HANA would be how SAP is catering to the demand of reducing the redundancy of data, and at the same time pinning the entire critical tables into the memory so that access to the data is faster. I am researching those factors.

I have roughly five years of experience in SAP HANA, because I started working on SAP ECC, on logistics and other components. After that, HANA became famous only in the years 2013 and 2014. Then I started pursuing HANA very, very actively. Right now, my journey is continuing and after five to six years I have a good amount of knowledge and experience on HANA.

It is stable.

SAP HANA is vertically and horizontally scalable.

Our banking system uses HANA primarily for our financial transactions. There are our SAP financials running on HANA. This HANA SAP was on the Oracle database. We have migrated it. It's very, very complex and took almost one year for us to prepare the plan and migrate to HANA finance. There are around 700 to 800 users using the database and they're not facing any problem. It's fantastic.

I would say I'm satisfied with technical support, buy it can be improved also. Improved in  terms of data warehousing, because HANA was introduced for data warehousing and because SAP wanted to catch the OLTP market. Now they have introduced many things to attract the OLTP customers, especially in banking and telecom sectors. That's okay. You have to keep your business interests also. HANA's architecture is the foundation of the language of data, warehousing, and design. For any project or product, if it's based on data warehousing, I would say HANA is the language for that because what data warehousing wants is a data warehousing database.

Primarily, it's not an OLDP, it's OLAP, online analytics processing. And where the data is not changed, the data doesn't change as frequently as a OLTB database. For that kind of environment, I think HANA needs a lot of improvement in terms of making it more columnar. It has to incorporate up level design a little bit harder, as well. 

You know MySQL database? Not Microsoft, MySQL. Microsoft is not SQL. M-Y-S-Q-L, has been bought by Oracle. Oracle bought MySQL, it acquired the MySQL company. If you look into the database, by default, MySQL engine is InnoDB. InnoDB is the default engine on MySQL. But, MySQL also gives you the flexibility of choosing your own engine. I don't want to know InnoDB, I have a huge Microsoft Excel file with around 10,000 rows, but I don't want to use InnoDB because I have to pay for that. To save those costs, at the time of starting MySQL engine, I can choose my type of data. Instead of InnoDB, I can choose Excel also. SAP HANA should give that kind of flexibility to its customers, making it more reachable to small SMEs, small and medium enterprises.

Now it is simple, because thanks to the cloud approach, it is giving a lot of flexibility to the customer, but if it wants to attack, hit the right target, acquiring the very, very small scale customer, who has around max 50 terabytes data or 100 terabyte data, a small scale company, small companies, that market should also be captured by SAP, not only the big companies. As the English saying goes, small things count. You can't ignore small things.

The initial setup is pretty straightforward. The only thing was there were a lot of parameters which had to be taken into consideration and any parameter at installation will be paid. But one good thing about SAP HANA is even if you miss a single parameter, you cannot agree to it for the steps. The further steps will tell you that, "you have missed this step. You first complete it, then you can come here." That kind of interlinking is there. So yes, SAP installation is pretty straightforward, and very easy and smooth.

I would recommend SAP HANA. No doubt I would definitely recommend it. But the thing is, if I adopt SAP HANA, my total cost of ownership in terms of having a functional consultant, as well as a HANA admin, would increase. I should first find a balance and analyze the data, "Do I really want to have HANA? What benefit will I have if I have HANA at my premises? And if I want to cut cost but also get the benefits of HANA, will the cloud option of HANA cater to my needs?" All those questions.

That is the company analysis I should do: what do they do differently? But many companies will be driven by the business needs, but at the same time some companies will also be driven by factors like the existing relationship with other vendors, like Oracle or SQL Server, and the kind of discounts they get when they buy that product. All those things will be there as driving factors. To answer your question, I would definitely recommend SAP HANA to anyone.

High availability and disaster recovery are very poor in HANA. High availability is measured on the barometer of RPO and RTO. RPO stands for recovery point objective, RTO stands for recovery time objective. The graph in which these two factors will be measured is from the five nines, the seven nines, or the three nines, that kind of factor. But it is a factor of my high availability. 99.9% of my database is available or 99.99999999%, giving a chance of 0.0001% for some kind of availability failure is because of natural disaster or some kind of electrical failures or something like that. So those are the factors you have to see for high availability.

My SAP HANA, technically, can withstand those calamities and recover itself from that disaster. That is called high availability. That high availability is there, but it is very, very, very minimal. If you're talking about high availability of HANA in actual high availability markets compared to Oracle and other RDBMS, HANA is a small child. If you remember when Microsoft SQL Server came into the RDBS market back in the year 1997, when they introduced the SQL 97, then they introduced the SQL 2000, SQL 2005. At that time, they introduced the high availability called Windows Cluster log shipping, mirroring the application.

At that time, in 2007 and 2008, Oracle introduced RAC, Real Application Clusters. Compared to the features of real application clusters, the Microsoft product was a small child. And Microsoft took that as a challenge and they improved and they improved. And in 2012 they introduced something called Always On. Always On is an improved version of high availability in SQL Server. HANA has to do that kind of stuff. HANA's high availability is immature.

On a scale of one to ten, I would rate SAP HANA an eight.

This is an in-memory database. It's designed to leverage the use of new generation, multi-threaded CPU architecture. We are service providers.

This is a very feature-rich solution with excellent performance. It's capable of integrating with most applications on the market. The stand-out feature of SAP HANA is that all data resides in memory. Processing is significantly faster, and the need and size of databases drop because there is no need to create and maintain tables that hold historical data.

As with all electrical products, this is an expensive solution and we'd like to see licensing costs reduced. 

We've been using this solution for 10 years. 

The solution is stable. 

The technical support is very knowledgeable and provide good service. 

The initial setup doesn't take more than a few hours. The on-premise version can be installed on public cloud and SAP now have their own version on private cloud. Installation is just a matter of preparing the operating system that has certain prerequisites, patches, and networking requirements that need to fill parameters.

The hardware to run a HANA database requires extremely big servers, makes this an expensive solution. 

There aren't many options available and this is a good product. I rate SAP HANA eight out of 10. 

We use SAP HANA for Master Data Governance.

The solution needs to work on its performance and make it faster.

I have been working with the solution for four years.

I am satisfied with the tool’s stability.

I would rate the solution’s scalability an eight out of ten. Our company has four users for the solution.

The solution’s tech support is good.

Positive

The setup is straightforward. The deployment took around six months to complete.

The tool’s subscription is yearly.

I would rate the overall solution a nine out of ten. You can use the solution if it meets your requirements.

I primarily use SAP HANA for procurement.

SAP HANA's most valuable features are monitoring, reporting, and price and stock control.

SAP HANA isn't user-friendly, and it's very hard to train newcomers to use it. In the future, SAP HANA should develop and review their offering for the construction field.

I've been using SAP HANA for six years.

SAP HANA is very stable - I would rate its stability ten out of ten.

SAP HANA's scalability is good - I would rate it nine out of ten.

SAP HANA was very hard to implement.

We used an in-house team.

SAP HANA has saved us huge amounts of time and money.

SAP HANA is very expensive for small to medium businesses.

I would give SAP HANA a rating of nine out of ten.

Our primary use case is for the database and the network.

The most valuable features I have found are speed, dashboard, and reporting.

There are a few areas wherein there could be a patch upgrade, and that can cover up the country-specific payroll areas.

I have been using SAP HANA for the past two years.

The stability is amazing.

There is a high level of scalability. We currently have around three hundred and thirty licenses.

Technical support is excellent. There has never been a case where I was not given an answer.

Positive

The initial setup is very difficult and not easy.

The deployment took two months to implement.

It is a good, satisfactory, and very customizable product. There has not been a situation where I have not been able to provide a solution to the customer. I think it is the best product.

The pricing is relatively high for both customers and partners.

I would highly recommend SAP HANA and would give it a ten on a scale of one to ten.