SAP S4HANA on AWS Reviews

We have clients who use SAP S4HANA on AWS.

The solution is deployed on the cloud.

The operation of the solution is good. It's easy to use and user-friendly.

The pricing is a little bit high.

I have used this solution for about seven years.

It's stable.

It's scalable. It's about 70% scalable.

I would rate this solution as seven out of ten.

I would recommend it to those who want to use it.

We are using SAP S4HANA on AWS for test cases.

The most valuable feature of SAP S4HANA on AWS is the latency and speed. When we use the various typical relation database, the performance was visible.

We had some storage and legacy migrations problems with SAP S4HANA on AWS.

I have been using SAP S4HANA on AWS for approximately nine months.

I rate SAP S4HANA on AWS an eight out of ten.

There could be many use cases for this product. The use cases will be different depending on the industry where it is employed. It could range from the manufacturing industry to the retail industry. The actual use case could be anything.  

The solution is deployed with two possible methods. One is the on-premises deployment (with AWS) and the second one is the cloud deployment. You follow the software development life cycle for deploying the solution. First, you do the project preparation followed by the solution design. This is followed by the actual realization of the design plan. In the final testing, you engage in three go-live activities. When this is successful, you follow it with an actual live deployment. With the go-live successful, there would be PGLS (Post Go-Live Support), which is nothing but the support aspect. So implementation typically follows the normal software deployment life cycle. The approach could be anything, like support could be a waterfall approach (project activities into linear sequential phases) or it could be a more aggressive approach.  

Because SAP is a part of ERP the features range from finance functions to manufacturing functions to quality control functions to procurement functions — anything you might need in development planning. So you can have tight integration between all the functions in which a manufacturing industry operates to develop market and distribute its products. The S/4HAHA platform provides insight into the processes which can become part of robotic process automation. S/4HANA as a platform is enabled for artificial intelligence and machine learning. So you can use it to help simplify your workload with automation.  

This is the latest offering by the SAP company. Of course, there are the pros and cons to on-premises deployment versus cloud deployment — especially as far as the infrastructure maintenance is concerned. There is not so much difference as far as activities are concerned. But having said that the cloud deployment is on AWS (Amazon Web Service). It is always the latest offering and the cloud is indeed today's emerging market.  

From what I understand, SAP is already at work focusing on improving the CE (Customer Experience) and the CRM (Customer Relationship Management) as far as S/4HANA is concerned. They are working with having better robotics, machine learning and artificial intelligence capabilities, which can work with this ERP. So there are already new concepts on the way. They are making a lot of use of Python technology, and they are making heavy investments to make it much more user-friendly and customer-friendly. Automation is at the center of their development focus.  

We have had an S/4HANA implementation for some time.  

The stability of the solution is fine. We have no issues with that.  

For scalability, the skill set required is very specific. You need someone who has a functional and business knowledge along with technical knowledge. A candidate or the consultant who has experience in the difference between the data technological concerns and the business trends can easily go through the entire deployment very easily. Having industry experience is very much required for deployment and scaling.  

As a consultancy, we provide some of the technical support for SAP. The support we provide is very much function specific. I am from a finance background. For finance-related support, I could be the key person in our company. For materials management, it would be someone else. Materials and quality management can be handled by a production management expert. One team member may be the marketing, distribution and logistics expert. Each subject matter expert will be deployed on the support of a particular ERP based on their areas of expertise. It is not a one-man show. One person can not run the entire support services as an expert in every area. It is very much specific to the role the candidate needs to play in addressing the subject matter as an expert in that particular function.  

As far as the deployment on AWS is concerned, it is the cloud deployment. It is a little complex. But once it is deployed, the post maintenance and the support services are very easy because the upgrades and maintenance are not handled manually. It is just like on smartphones where the patches get auto-upgraded. In the same way, the patches or the upgrades are automatically pushed to the ERP on cloud. So there is no manual maintenance required going forward. There is no downtime required. For these reasons, clients are attracted to going with cloud deployments. But others are still going with on-premises deployments for various reasons.  

There are a lot of competitors coming into the market. The main organizations as far as IT or information technology companies are involved already. We have Infosys, there is Oracle, there is Siemens, there is Accenture, there is Cognizant — all of these are from the IT organizations' perspective. From consulting companies, we have got the Lloyd Group, KPMG International (Klynveld Peat Marwick Goerdeler), PricewaterhouseCoopers, and others who are all into this. There are other up and coming competitors and consultants like BDO Mauritius (Binder Dijker Otte). All these various kinds of organizations are good at deployment and the support of SAP solutions. The main difference is in their approaches to providing solutions that are on-premises or on the cloud.  

The advice that I would give to people who want to use S/4HANA on AWS is that a specific study needs to be involved in the implementation process. It is what we call a discovery session. The idea is to discover all the independent needs for the use of the product. This includes things like the size of the organization, the size of the industry, the number of users expected, the revenue, et cetera. It should also include projections into the future aspects of organic and inorganic growth. The budget may be the main issue for many organizations. The deployment plan should be created based on keeping all these discovered factors in mind. This can affect the deployment model or choices as to whether to go for SAP S/4HANA on the cloud, on-premises or if another ERP may be a better choice. But in any case, all the factors need to be taken into consideration. It is not a black and white decision.  

On a scale from one to ten where one is the worst and ten is the best, I would rate SAP S/4HANA as very near to a ten. Maybe nine because there is no competitor like SAP in the market right now to compare the product to and maybe there is room for improvement. I think that Oracle and Microsoft are looking to close the gap. But, looking at the current market share of SAP, it is at the top so it is near to a ten.  

Infrastructure-wise, if you have your own data center and you're running SAP ECC, a very initial or the older version of SAP ERP - if that's the case, you need to maintain your own data center. You need to maintain your own infrastructure away from the server or network. SAP offers cloud hosting to help with that.

You can directly host your SAP system on AWS, Azure, or other cloud hosting services. SAP also provides its own cloud hosting part. That way, infrastructure activities are smaller. You don't have to have your own team of infrastructure guys to maintain each and every thing. Your infrastructure services get minimized a lot. You can save costs.

Issues related to the infrastructure also get reduced. Servers, et cetera, get reduced. Everything is stable and can be contained in dedicated AWS services.

They have their own instances where you can host your database. You can host your system, wherein AWS completely takes care of that hosting part. You just need to maintain and run the system and you have and just pay for the services you want to, which you have acquired, or which you are utilizing. It's pay as you need. The cost gets minimized a lot for a bigger ERP like SAP and you need to have any minimum resources from infrastructure which you need to take care of. It's a couple of SAP business administrators and the cloud architect. That's it.

Therefore, in terms of maintenance and cost, it is reduced by a lot and when you're hosting a SAP system on the cloud, the system is very fast. The system is secure and stable. And the accessibility of your SAP system to your business users is very properly organized so that there is no lag in terms of performance or in terms of integration is getting concerned. 

For the cloud part, it's very good. However, some customers are a bit skeptical and a bit hesitant regarding putting their data on the cloud. And, even if they want to put their data, the business transactional data, or their company data on the cloud or not, you will still have to take care of all these licenses from a security perspective. Just recently, we had a European client who wants to work with the SAP system, however, they don't want to go on the cloud. They want to go with the on-premise solution. This is possible. For this particular solution, with the AWS angle, it won't necessarily work for them. We'll have to go with the client's requirements. We'll host on-premises.

The integration part is quite secure and stable. Only the part from the customer side that's been raised is regarding their data hosting part on the cloud. Otherwise, we don't see any issue with hosting SAP on AWS. It's always good to have on there since it reduces cost. It reduces your maintenance-wise integration also. 

They are a very big company and their own data centers although you have to make all these protocols and service agreements so that the data will not get lost. You have to take proper care of the data. You have to take daily backups before any availability or any optimization. On-premise we also used to take backups, however, it was very manageable.

There are a few complexities when it comes to licensing that could be simplified. 

Regarding SAP S/4HANA services, we have been using these services for the last three to four years. Until 2017 or 2018, we were into SAP ECC. Therefore, our consultants are having major experience from various backgrounds. As a company, as a business service provider, we've used this product for the last three years.

The stability is fine. We do have a certified cloud consultant with us who is AWS-level certified and even our SAP business person is also SAP S/4HANA business certified. We do have our certified consultants who can take care of things and ensure it runs seamlessly. There are no performance issues. 

The solution can scale. We just have to identify how many users are there since we have to identify the instance of the database. That is very important. The common instance of the database needs to be created so we need to identify properly and number of CPUs, number of database instances, et cetera. All those things should be identified and once those are properly identified, then making and implementing the system and designing the system and running the system is not an issue. 

We have three clients that deal with this product.

We can always log and raise incidents. From the system side, only business and cloud architects are needed to manage any technical issues.

The initial setup was not a big task. We haven't had any kind of issues. The last time we did it within two months by completely making the setup of the SAP landscape quality. If the requirements and the services are getting properly identified, then the integrations became very easy.

For technical staff, we deploy four to five staff members from our side. We have a couple of cloud architects, one DBA wherein we have to align sometimes the SAP person to take care of the SAP node implementation, all those things, and to our SAP business side. They all ensure the implementation part is getting done. If it's a very small stack, then two to three consultants are enough. If it is a big one, then we might require four to six staff. It all depends upon the size of the landscape, how many cloud instances, and how many data instances we have to implement. 

We had a competent consultant that took care of all the requirements and made the setup simple. 

The cost is quite reasonable. It's less than if you had an on-premises setup or used different clouds. 

You do need licensing from the AWS side.

The cost may vary depending on if a company is taking a Greenfield approach or a Brownfield approach. If you're migrating your older systems to a newer system, then you have to upgrade your licenses, however, if you're starting with a completely new system, as in Greenfield, then you have to purchase a few extras, which might be a bit costly. The rate varies from SAP regarding those licensing parts. Each package depends completely upon the hosting instance, the cloud instance. It depends upon how much big infrastructure you want. 

We are an SAP partner. 

We deploy both on-cloud and on-premises versions. We have done SAP on cloud on AWS and the latest cloud solution, which is provided by SAP - Horizon ERP. SAP is increasing a lot. We have more returns from Horizon SAP compared to AWS, however, with AWS, we do have our consultants on the infrastructure side - including SAP cloud architects and SAP business consultants who are well versed regarding the requirements.

I am into the development area, but for me and my organization, I am looking after the SAP business development part for the client acquisition and sales and marketing.

Whether the solution would be a good fit for a company depends upon three scenarios. If the customer is a bit hesitant about the cloud, for example, then we go for SAP on-premise. If the customer is not hesitating about the data, then SAP and AWS are also good, however, SAP is also coming up with their own SAP online solution, which also might work for some people. Cost-wise, SAP AWS is always better.

I'd rate the solution seven out of ten.

We primarily use the solution as an end-to-end integration. Most companies are already using financial software, but they want to have software which can offer complete integration. In our case, it's finance, material management, sales distribution, and HR.

There are two main features that we find very valuable. One is the interface and the new user experience. That's really, really helpful for the end-user. The second is the HANA database itself because it speeds up the process. In other solutions, like Oracle, there is a lot of redundancy that slows things down.

The new product has SuccessFactors. If they can bring it in on-premise as well, and basically replace SCM with SuccessFactors on-premises, that would be great. It will allow for more revenue.

The solution's weakest area is technical support, which needs to be improved quite a bit.

The solution needs a warehouse management feature. Right now, there's a built-in WM, but they don't have an EWM extended warehouse management built-in, in S/4HANA. It's a separate product. So if they can add that, that would be great.

I've been using the solution for three years.

The solution is very stable. We've had no issues at all.

The solution is scalable. With the new data connectors that they have and the new FCI NCPI integration facilities, it can be scaled up with any other third party component or even Zippy products.

Technical support is one area that they really need to improve. When you get a ticket, the response you get is "We are working on it." Yet it will take five to 15 days or sometimes even more than that to get a solution.

With the S/4HANA, it's very simple. But prior to that in ECC it used to take a lot of time, whereas, in S/4HANA, you can easily deploy, and have an implementation in three months.

Pricing depends on a lot of factors. For example, which month of the year it is. Is it close to the end of a quarter year's end? Usually, we get the best benefit out of it if we know the exact ICP events. Otherwise, price-wise, they're expensive. If you know when their quarter closing or annual closing are, you can get pricing similar to Oracle, and in some cases, even IFS.

We use both the on-premises and private cloud deployment models.

I'd rate the solution 7.5 out of ten.

The main interest of my customers is in service formulations and telephone centers right now. I think most of the things are very common. The application of customer assistance is a major thing as is registration automation. Apart from that, there are a lot of restrictions based on destinations. A lot of customers have to be removed from the cloud because of the basic restrictions and standards. This is because if you are going on to SAP S/4HANA on the cloud, you are not allowed to serve all the destinations because of restrictions.  

Being customers who have been using the product for some time, my clients have a lot of customizations. Now they have to follow some regulations and they need to either remove customizations or bring them current with the new product and the cloud environment.  

If you look at this product in comparison with other products in this category, it has more features than really almost any of my customers' needs. But it is specifically much better in financial ability in the way it controls costs and transactions. It is much better than most of the other products and they can not match it in these features or performance.  

One thing which is really killing a lot of people using this product is because they have been using it for twenty or twenty-five years and a lot of the customers' customizations are not working anymore.  

A second thing that is a problem for the product is the cost — particularly on the hardware side it is too high. If you have to procure your server for S/4HANA the cost is a problem. I mean hardware cost is killing a lot of people and the costs are complicating matters for those who want to stay with the product.  

For HANA the biggest issue which will need to change is the GUI interface. It is still the age-old GUI and this needs to be changed. All the other competitors are moving to a new phase in development of user experience and they are moving to new interfaces like AngularJS and other technologies that are new. Which things or trends become most popular still remains to be known. But the front-end needs a lot of thought.  

I currently have two clients for whom I am doing work with this product off-and-on over a period of time.  

In my experience, the product does not have any glitches or stability issues. But I do not think I am able to comment on that because I still hear feedback from people who are talking about providing solutions for issues they are having with the product. From what I hear from some people is that the product implementation still needs at least a couple of years to get real stability in the database. It is the response I am getting from the customers who have implemented it, but I have actually not actually seen it myself. It is not possible for me to say whether it is the product that has issues or if it is what the clients are doing with the product that creates the issues.  

I don't think it would be right for me to comment on that package regarding the scalability. I don't think it should be a problem, but as far as having the experience with the product to be sure, I am not at that point. It is too new and I am just helping clients who are implementing it right now.  

The maintenance of this product requires a different number of staff members depending on the deployment model. I think a customer will need to make their own decisions about this. Accountability on an outside service will be very different than in house. In house, you will be dealing with a team of three to five people. These will be some kind of functional experts who will be performing in different capacities. The size of the team will depend on what the company is planning on using and what they need to deploy and maintain. So for some clients, they may need a bare minimum of 4 to 5 people and then, in addition, they may need other support services.  

If there is really ever an issue we probably need to contact support. If something is going wrong and we contact them, the response generally good. I do not have any problems with technical support.  

But the other thing I do know regarding the technical support is that they need more time to build their database for this version of the product. Right now the product is somewhat new and very few people are available who have a lot of experience with the product completely. The community is still pretty small.  

So it will take another one or two years to really compile expertise and a strong background in working with S/4HANA and finding those people who have that expertise is going to be difficult. The real problems that the user base will face might only be reported once every 5 days over a period of six months. It will take some time to build out the knowledge and for the user base to grow.  

I did not really change to S/4HANA, I was working with it for some time in other versions of the product. Some clients felt like they had invested a lot in the product, so they moved up to the new product. In a sense, I had no choice but to switch to it.  

The initial setup is really fairly simple. If you have a basic understanding of databases and SAP the setup is not something that is complicated. It is pretty simple. The deployment process takes about 20 days or a little more than two weeks because you need to reconfigure everything. There are other things that will take more time.  

The deployment of S/4HANA takes maybe two or three people. You will need one who is a DBA setting up the back-end database configuration and the one who is an application specialist. They will be doing all the configurations.  

We are doing the implementation ourselves, absolutely. 

The licensing cost for the product is not so high, but the cost for the hardware you need for it on-premises is very high. I can not verify the degrees in comparison to other products, but I know that the hardware cost is too high because. There would not be much of a change to reduce it down so that the cost could more in line with competitors.  

The advice I would give to someone who is looking into implementing this product is to wait for a year basically so the product will mature and stabilize. The company and the users will learn what the issues are that have been discovered by other people and then maybe it is OK to take on S/4HANA as a project. The project itself is going to take eight to nine months to get completely on HANA. If this part of your business is the backbone of your industry, you can not afford to make this kind of risk.  

On a scale from one to ten where one is the worst and ten is the best, I would rate the product overall as between a five and a six. Closer to a five at this point. The problems are that the GUI should be updated and the time needed for real user issues that will come up, be identified, and be rectified. Probably after that, you will start seeing the results with the product moving in the market and raising awareness and popularity. It is more of a wait-and-watch as of now in my estimation.  

Our customers use the solution to deploy S/4HANA.

The product’s high availability is its best feature.

The solution is costlier than other products.

I have been using the solution for six to seven years.

The solution is very stable. I rate the stability a ten out of ten.

I rate the product’s scalability a nine or ten out of ten. Our customers are medium and large enterprises.

I rate the ease of setup a nine out of ten.

One person can deploy the solution in a few weeks.

I rate the pricing an eight out of ten.

An enterprise customer should do a proof of concept before purchasing the solution. Overall, I rate the solution a nine out of ten.

The cost is a factor for our customers, so that is an area for improvement. That is, compared to its competitors, SAP S4HANA on AWS is a costly solution. 

More availability zones will help customers choose AWS.

I would like to see features that provide easier onboarding for ERP solutions like SAP. SAP has already partnered with S/4HANA on AWS for hosting its public cloud as well. More educational videos for customers to choose this cloud path would be great to have. That is, providing more documentation and marketing material would be better.

I've worked with SAP S/4HANA for four years and on AWS for about four years.

It is indeed a stable solution, but it depends on how you architecture the component in AWS. If the component has the right architecture and is properly provisioned and placed, then it will be a stable platform.

It is scalable.

Compared to its competitors, SAP S4HANA on AWS is a costly solution.

From a business process perspective, I would recommend that customers stick with the standard, which will help them to easily adopt the solution.

AWS is a market leader and pioneer in realizing cloud concepts and is once step ahead of its peers.

On a scale from one to ten, I would give SAP S4HANA on AWS an eight.