SAP HANA Reviews

Some functions have good performance.

I think a lot of areas need improvement. There seem to be a lot of requirements.
In Taiwan, we have a general universal invoice system in our government, and we need more support for this.

I would like more technical documentation. I would like it to be easier to find online help or have a better launch-based service.

SAP has a lot of functions, so we need more best practices and more detailed documentation on industry solutions. For example, it would be good to have documentation on why a certain process needs to be set up and which kinds of configurations need to be set up.

Before SAP HANA releases the next update, they need to run more internal tests.

I've been using it since 2016.

The 2020 version is stable.

It is scalable. We have more than 100 people using SAP HANA. Most of them are developers and consultants.

Technical support has been more helpful than before but still need improvement.

The initial setup proceeds better when best practices are followed. It can take more than a week to implement the system.

We have one team that handles the maintenance of the solution.

We used an in-house team for the deployment.

On the basis of my experience, SAP HANA is better than other solutions.

I would recommend SAP HANA, and on a scale from one to ten, I would give it a rating of eight.

We are currently using the solution for planning, sourcing, and ordering from a contract perspective.

We have found that the Fiori Apps are particularly good.

I would like to see improvement on the feedback from the road-map; it is currently extremely hard to get insight in this area.

I have been using this solution for four years.

The stability of this solution is extremely good.

We have found it to be extremely scalable.

The initial setup was complex, but this was due to the nature of the current project which is large and complex. However, for smaller projects, it has been more straightforward.

The implementation was carried out in-house, and we also implement the solution for our customers.

The price of licensing is dependent on the size of the project, however, we have found that there is scope to negotiate the cost.

If the solution is implemented on-premises there may be some extra costs for hosting etc.

I would rate this solution as a seven out of ten.

We use this solution to custom build features. We are customers of SAP HANA and I'm a solutions manager working for a retail company in Finland. 

The product handles high volumes very well and provides good integration. HANA has great databases and we're able to have a lot of custom-built features. I think this is the best solution for us given our high file volumes.

The SAP ERP processes are quite complex for us and it's a challenge. I don't like the presentation layer tools on the analytics side, it's too complex. I'd like to see a consistent analytic system as those tools and their capabilities are not easy to select. An alternative could be for them to offer the option of access to other solutions.

I think the solution is relatively stable but in some cases, it can depend on the service provider and their capabilities. We handle about 40 promoters, all in Finland and dealing with high volumes. Our market set is very high here.

I think it is highly scalable but it comes at a financial cost. We currently have around 1,000 users. 

We use the support when we need it but we have quite good capabilities ourselves. If we're having some challenges then it can take time to have them resolved or to find the root cause of the problem. We've had some ongoing challenges that have taken quite a while to resolve. 

If you have some experience, the initial setup is quite easy. 

We are always discussing ways to optimize memory usage and hence our licensing costs. The solution is quite expensive but we also get a lot of value-added because of the high level of integration. I think it's worth the money but it's a fine balance. 

I would recommend SAP HANA solution for ERP but not necessarily for analytics. There is no other solution that can provide the value added that we get from SAP, despite the challenges. 

I rate this solution nine out of 10.

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. 

We work with the latest update.

We use the solution as a database. We primarily use it for the SAP application. Some of the use cases involve CDS Views, which provides a quicker processing of the report and the application.

The in-memory database is a good and valuable feature.

Since we use BW, we are required to use an SLT tool to carry out the data for generating the reports. But, when it comes to in-memory database in respect of the realtime reporting, I do not see why this report cannot be made available from the system itself. This would allow for some partitioning of the database, so that there would not be a need for the EMP in respect of the realtime data.

The initial setup was complex. I am talking about how the data is replicated to the site. We had an Oracle Database and did replication to the VR site. Yet, when it comes to HANA, we are forced to work out the method for ensuring that this replication works as it should. It is at this point that the solution becomes stable. 

Technical support could be better. When we have requested this, the tendency has been to instruct us to implement a note and keep them apprised. In reality, there is no one who helps us with actual troubleshooting of the problem. 

The pricing is a bit on the high side. 

While I would definitely recommend the solution, I would caution that one should employ the proper resources that are geared towards the system. Unfortunately, SAP does not provide a structured training program, which means a person must rely on multiple system integrators and some service providers.

We have been using SAP HANA for more than three years.

The stability is very good and we have encountered no issues regarding it. 

The initial setup was complex. I am talking about how the data is replicated to the site. We had an Oracle Database and did replication to the VR site. Yet, when it comes to HANA, we are forced to work out the method for for ensuring that this replication works as it should. It is at this point that the solution becomes stable.

The solution is easy to scale.

Technical support could be better. When we have requested this, the tendency has been to instruct us to implement a note and keep them apprised. In reality, there is no one who helps us to actually troubleshoot the problem. 

We had already been using SAP when we switched from it to Oracle, because all of the innovations were taking place on HANA. 

The initial setup was complex. I am talking about how the data is replicated to the site. We had an Oracle database and did replication to the VR site. Yet, when it comes to HANA, we are forced to work out the method for for ensuring that this replication works as it should. It is at this point that the solution becomes stable.

The deployment lasted six months. 

We deployed with the help of a vendor.

No real maintenance is required. Data volume management is needed and all the reports are available, based on which the maintenance is easy. 

The pricing is a bit on the high side. 

The use of hardware does not incur additional costs. 

There are 40,000-plus users making use of the solution in our organization.

I rate SAP HANA as an eight out of ten. 

We are solution providers. We are a supply chain organization and we deploy and supply chain solutions for our customers.

We have a host of solutions and for each of our customers based on their environments. We customize their platform and deploy it.

SAP HANA is one of our database endpoints.

It's easy to use, and the Hana Studio is pretty good.

The main issue that we are facing is with the connectors. The JDBC connectors are very slow. We have been trying to connect with our SAP HANA database to our customers.

It's a simple Java driver and there is no proper documentation available anywhere with clear steps. We have to rely on several documents which creates confusion.

The initial setup could be simplified.

Also, we don't have to option to pull up the data from the object structure in SAP HANA. We can only pull up certain objects. It doesn't provide you with a comprehensive list.

There are limitations in connection with SAP HANA. There has to be a better or easier way to connect the databases with other platforms, maybe using Java code or other types of code. It would be very good to have the documentation on how to connect.

I would like to have flexible connecting mechanisms for connection with Java or different types of solutions to SAP HANA on cloud or non-cloud solutions.

They could come up with something similar to the SAP HANA Studio type of modeling.

I would also like to see the capabilities to extend the API. If they had specific APIs, it would be easy for us to connect.

My company has been using SAP HANA for ten years.

We are using the latest version.

It's a stable solution.

It's a scalable solution. Because it's an on-premise infrastructure and SAP this is the best support for most of our customers, scalability is taken care of.

We are an SAP house. We have more than 1,000 people who use this solution.

I have not interacted with the technical support. Other teams may have, but my involvement is more with the integration. 

The initial setup was a bit complex. We were told to download it from the marketplace, but when we tried, it didn't work. We may have been doing something wrong, but we did not have a clear understanding of how it should be done. We also had difficulties with the trial version, it was not working.

There are two options:

1. Download SAP HANA then import it
2. Go to the marketplace and download the connector

For testing purposes, if they could provide us with clear documentation, it would be very helpful.

Licensing is on a yearly basis.

We are using the paid version. We pay $200 on a monthly basis.

I am not an expert in HANA. I build the enterprise bus that integrates with SAP HANA as well as other systems. We have built our own integrated platforms.

The recommendation of this solution would depend on the use case and the requirements, and the price will be considered.

I would rate SAP HANA an eight out of ten.

We use it for database virtualization.

The main feature is that the processes are very flexible, they are able to be adapted to the business and their departments. The solution is very good and has covered all functional areas needed in this type of solution.

There could be better management for faster updates, last year there were some changes in India to the e-invoicing feature. During that time, there was a couple of updates that we had to wait until the release happened before we could do the implementation, this was a time we had to wait. They are pretty good at releasing updates but that time it was not the fastest.

I have been using the solution for a few months.

I have found the solution to be stable, it is very robust.

There is the ability to scale the solution by increasing capacity with no problem, it is very flexible. We have almost 34,000 users using the solution.

We had some issue with support in the past because they did not have enough availability. However, they have improved and now they are okay. 

Since we have been using the solution before we did not have any issues with the install. There were not any major complex operations. However, there were some challenges but we had the full documentation with us and it was not a problem. 

The price of the solution could be reduced, it is expensive. If they wanted to go into other industries and sectors the cost is on the higher side. They cannot go into each and every sector. If the cost was more reasonable, then it would be easy for them to enter more markets. This would be a disruptor in the industry because it would be used more often than other solutions, which would be good for the company.

I do recommend this solution but at the same time, it is expensive. The cost will not be able to be afforded by everyone such as medium and small scale businesses.

I rate SAP HANA an eight out of ten.

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.