What is our primary use case?
I manage an SAP Central competence, and we are working on multiple S/4HANA implementations. Our Webex begins with leading teams. We've done major and complex implementations in the network.
What is most valuable?
SAP InGen is not just for HANA. The most likely features are that it is scalable. You don't have to worry too much about volumes of data, even if your transaction volumes go up.
It is easier to accommodate due to standardized features. It is easier to maintain and even find the workforce to maintain it because an SAP standard feature is globally the same. So it's not dependent on individual people having expertise, unlike custom apps where you'll have that dependency on particular developers or a consultant.
Additionally, there is a rich, diverse workforce available. Many innovations are coming up individually from the ecosystem as well. These are prime features. If you go module by module in MM, SD, and other individual modules, there are many features not offered by any other ERPs.
You can build S/4HANA in S/4HANA, and you can build SAP as your end-to-end SAP, which covers everything you need. SAP Analytics, when coupled with an active SAP SSP system, allows you to see material movement or your sales order history end-to-end.
You can view your inventory and supplier ecosystem, enabling you to see multiple factors with all the data in a single data model. If you have multiple different systems, matching different patterns can be confusing, however, it is easier to draw connections and identify patterns in this setup. This is the biggest advantage.
What needs improvement?
A lot of people would say the pricing. SAP is seen as quite expensive even now. It doesn't work for smaller or medium optimizations.
The licensing and pricing could be looked at. In Brownfield migration, the trade-off between greenfield and brownfield means you either keep it clean or match the business requirements. Sometimes, it's not possible to do both.
While ValixAPI provides significant support in making those decisions and the SAP consultant is very useful, we are still dependent on past history and how it was originally set up. I wouldn't call that a real disadvantage, yet more accessible consulting would be beneficial.
Incorporating all other cloud products, like APO or IPP, into the S/4 house might also help.
For how long have I used the solution?
I have used the solution for the last five years.
What do I think about the stability of the solution?
In comparison to ECC, definitely, because of some of the simplification and eliminating some moving parts, it is better. But performance and stability also largely depend on the infrastructure.
Whether it's on-premises, how well it is maintained on the server side and resources, or if it is right with SAP, there is some standardization. It depends on what type of infrastructure we have and what model we have. The operating model is more than the functional side. But comparing only the functional side or the application side, I would say it is better. It is easier to manage.
What do I think about the scalability of the solution?
Scalability is a key strength of SAP, especially for HANA, compared to all the other ERPs.
How are customer service and support?
The Mac support and options depend on the plan we have taken. The support is high quality but also very expensive. A traditional challenge with SAP support is that SAP teams only support the standard functions, which are part of the product. The custom support is left to the level two teams. This is strategic from SAP's perspective, yet as an end user or customer, I would prefer equally good support for custom success rates. This is happening through the partner ecosystem, but it can vary in terms of quality, depending on the partner and many other factors.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
We work in a competitive world with simple Microsoft versions and Oracle for certain functions, but not in the same business area. I have also worked with Becca, however, that was more on the CRM side, not on the RDP per se. Compared to Oracle and PeopleSoft, SAP is quite ahead.
How was the initial setup?
The complexity is more because of the business process and organization rather than the product itself. The product can be simple if your process is simple.
However, someone with a straightforward process may not want to invest in SAP in the first place. So you'll always have complex processes, or at least they need to be at a certain volume threshold to warrant an investment like SAP.
What about the implementation team?
For deployment, splitting it into preparation, functional readiness, technical deployment, and migration should involve a minimum of 30 to 40 people. However, if you only look at the migration and setup, the technical part alone should involve around 15 to 20 people.
What was our ROI?
I would say it's above-average ROI. It's not the best, primarily since the significant investments and the timeline it takes to recover those investments, but it's better than many alternatives.
What other advice do I have?
We are working with SAP colleagues and some partners. There are multiple parallel implementations and migrations going on. We are working on both S/4HANA migration as well as SAP upgrades.
The overall product rating is nine out of ten.
Which deployment model are you using for this solution?
On-premises