Back to standard

Back to standard is the leading principle* in every S/4HANA project. A common question at meetings is*: can this be achieved using SAP standard? But why? Everybody involved in an SAP project, and mostly customers*, know that it is not possible to continue to use SAP solutions like they were in the past. Every feature that is provided out of the box by SAP is one feature more a customer does not need to develop. Not only does this reduce the development costs. This feature does not need to be maintained. Its continuous usage demands less testing, less people effort and of course: new features are introduced by SAP and the usage should not be affected by future upgrades.

SAP put great effort in ensuring that their standard solutions are discussed by customers. The effort is a success and customers, key users, consultants, and developers are talking* about how to use as much SAP standard as possible. It is now a common understanding that every line of custom code is a burden. It is code that must be maintained, adjusted to new requirements and binds resources. Developers that are busy fixing old code instead of being involved in solutions that add value to the company are problematic. Developers are a rare resource. Allocating them on things that you get out of the box is a bad investment.

With these constraints in place, it rarely makes sense to not use a standard solution just because it does not fit 100% what key users want. Given that key users understand this too and that they accept that a solution that gives them 80% of what they need is sufficient, customers can go back to standard. It’s a win for everyone. Over the last month there were a wide range of different events in the SAP universe. At these events, SAP preached that customers should use their standard software (making the case for public cloud). And if a customer cannot or does not want to go to public cloud, at least custom code should be written in a way that at least keeps the core clean. Making it easier – or even possible – to go to public cloud later. The examples discussed went from highly standardizable HR processes to very custom specific programs. For many of these cases, back to standard is doable. HR being one of the simplest ones. Most of the HR processes at customers can be used as-is and as SaaS. HR is rarely where company differentiate and depend on custom defined processes. Transactions written by a developer specific to the do-as-I-want key user requirement are another example where back to standard is doable. Adjusting some parts of a standard transaction might be achieved by using Screen Personas or UI Flexibility. With custom fields and logic maybe not even needing a developer.

There is only one small problem. Small, but spoils the story told so far. You can use SAP standard software when there is a standard available. What to do when SAP does not offer a standard solution? A customer might want to go back to standard, but when there is nothing to go back to? Go back to what exactly? SAP offers solutions to a wide range of business problems. But not to all. Not to all business processes. Or does not offer it for some specific business processes. To close the gap, companies can look for a partner that offers a solution for their specific industry process. In case a partner once worked with a customer from the same industry chances are good that the gap is closed. It is possible to close the gap in SAP’s portfolio with a packaged solution. Maybe not exactly back to standard, but still better than having to code all by yourself. As long as the vendor is providing support and updates / adjusts the solution to future SAP releases, it solves the problem. It is clean core and (sort of) back to (vendor) standard.

And if there is no partner solution available? When the custom code may be an industry best practice, but just for a small area that is of no interest neither for SAP, nor any other vendor? Or the custom solution is used to implement an industry process that is specific to a customer situation? What when neither SAP nor a partner is offering a solution? What if the custom code solution is the industry standard? A standard SAP does not cover? What now? No standard available, no 3^rd party solution, no back to standard possible. Not a perfect situation, yet this happens before and will always happen.

SAP customers will always need to develop from time to time a custom solution. Realize their custom process in code. Just as with the over-developing of custom apps that should never had happened, there will always a wide range of scenarios where custom apps are needed. Custom apps are sometimes not optional, they are a fact. The are needed, simply because there is no standard available.

Problem is: when you take a closer look at the problem, it is not uncommon to find out that this affects many other companies too. Yes, it’s a paradox. The solution is unique, yet, at the same time, not. How each customer does it is unique, but there are overlapping parts they share. The process is too unique for SAP (or a partner) to offer in standard, but parts are shared. Maintenance, order fulfillment, intelligent construction sites, risk analysis, planning, etc. The process is individual, one reason for the competitive advantage. But not 100% of the process. 50% might be common and realized in a similar way by another company.

You might even find them at events where they talk about this. Presenting their custom solution. And you find out in a discussion with them that they face the exact same problems you do. That’s when you might realize that your specific problem is an industry best practice you must implement. Ideally, exactly what SAP should solve with their standard software. Yet, SAP ignores it. Maybe it is still too specific for SAP, or only suitable for a small region. Might be in the backlog for years, not enough budget, people, time. Or simply not doable due to some other reason. Doesn’t matter: a problem that other companies have to solve on their own is not covered by any standard software.

Companies can ask SAP to implement it. A custom app that goes into SAP standard. Enter some sort of co-innovation with SAP to influence the product roadmap with the goal to get features into standard. For instance, via customer influence, or DSAG or ASUG. Or in closer collaboration with SAP. This works (partially). The problem with these approaches to influence the SAP standard is how they work. It is hard to get an overview of what is currently worked on. What the status of the backlog is. Which features were requested, what is the status of them? Customer Influence is nice, but it is still a place where ideas die. A request can be declined by SAP simply stating: not planned. Or not having the feature is: works as designed. And that’s it. The backlog of a product, the maybe already disregarded features, not doable features due to internal demand or strategy: this is hidden information. A customer might opt for Co-Innovation. A very nice idea. But it is still a challenge to get a global view on the topic. Who else is involved in a co-innovation that affects the features? A global list of active iniatives. A global backlog of requested features? How many other customers tried to get a feature into standard and “failed”? This part is obviously not transparent. Opening the development process to such a degree is a risk. But is minimizing the risk for SAP a good fit for customers? Aren’t then the customers the ones who suffer?

Why not make it easier to see which features are in the pipeline? Who requested and why it was accepted / rejected? Vote on the features to not only get them into the backlog (as via Customer Influence) but also to prioritize them. So it is not mainly internal SAP demand that drives implementation, but with way more weight from customer demand. Directly influence the next release. The list can be discussed at customer group meetings, it can be like a ticket, discussed at events, meetings, etc. Solvable problem. Main thing is to get away from: added to the backlog, one day it will be available. And get to: feature is now put on the priority list by x customers, better start the feature implementation now.

Product roadmaps from SAP are many times just like your Birthday party: you know you will get something; you know also from who, but never know exactly what. But you still must organize the party and clean up afterwards. With better transparency, a feature brought in by several customers and (still) rejected by SAP: this might be something for partners to jump in and offer a solution. A bidding process can be included. Why not? Partner says: I’ll implement this given that x customers commit on buying it. Or maybe even for customers to join forces. Of course, this means that this is a challenge for SAP. Many people will have to change how they work today. Focus on customer will be redefined.

Back to standard is the right decision to make. SAP must ensure that their standard covers as many areas as possible. Back to standard needs a standard you can go back to. That’s the missing part from SAP. Partner solutions can fill the gap still left. Customers need to get a simple overview of what is requested, planned, or rejected. And they need to get a better voice in deciding what gets prioritized.

* or should be