No-Code Programming Will Kill Parts Of SAP ERP

Graphical editors for data modeling are standard. ERwin, Sybase PowerDesigner – there are many options available. I would like to split the business logic into two parts. One is the actual logic, e.g. how to calculate a loan payment plan – which requires programming for sure – and the other part is more workflow related, e.g. when a product is ordered the stock must be reserved. The latter goes into the area of Robotic Process Automation and graphical workflow editors – anybody remember the 2008 project Galaxy? Anyway, the second part can be solved using no-code tools.

Building a nice user interface is, as I keep saying in my other posts, by far the most difficult part. But UIs are also the component where no-code programming could be most valuable. SAP and other companies have offerings in that area. The SAP Abap Screen Painter is one ancient example. Fiori has no tools worth the definition of no-code yet, but that is just a matter of time. If I managed to build a graphical Fiori editor as a prototype, SAP can do it for sure.

Standard software vs. custom applications

Once all these building blocks are available, the question of standard software vs. custom applications starts to get interesting. Nobody in their right mind would want to re-develop an entire SAP ERP system from scratch. However, all companies are different and customizing an R/3 system is not cheap, either. For S/4 Hana, we can reasonably assume that customizing will get even more expensive. If that is the case, companies will have the choice to either adjust their business model even closer to S/4 Hana, or do something else – no-code tools look like an enticing option…

The costs of an ERP system are a given, customizing expenses must be added on top. How the costs of customizing will change over time is a good question. On the one hand, tools will get better; on the other hand, the demand for more changes will grow. Assuming no-code programming does live up to its promises, the dev costs of an entire custom application could be significantly lowered.

The first ‘Break Even’ point might be reached as quickly as this year: The point in time where buying an ERP system plus customizing is more expensive than building an entire tailor-made application in house using the no-code tool chain. As the ERP system is very feature rich to serve a wide range of customers, the license costs are also high. However, not all these features are used by an individual customer. Building a custom application with just the needed functionalities would then be cheaper than an ERP license!

Note: Costs mean everything here, including license or development costs, cost of operations, cost of risk, and opportunity costs.

Prediction

Obviously, the entire equation depends on the degree of necessary customizing. In a perfect world, the ERP system would be so flexible that no custom development would ever be needed – all would be available already. In some modules, finance comes to mind, as the differences between companies are so few, and hence SAP ERP leaves nothing to be desired. Here, I would expect the ‘Buy’ dogma to win over ‘Build’.

The sales module is designed for manufacturing: Take raw material A, attach it to material B, and sell the created product. And yet, I have seen it being used in the chemical industry, where A and B are mixed and, depending on the quality of the chemical reaction, either a high-grade C or a low-grade D product is the result. In a brewery, the cask of beer half full is shipped and returned ¼ full. The billing must contain the consumed difference. For these examples, a lot of customizing is needed.

My prediction is that cloud hyperscalers like Microsoft will provide such a development environment. Building new applications yourself will be cost effective in areas where ERP requires high customizing efforts and, thanks to the openness of the ERP system, the custom applications can work in unison with it. If that happens, the slogan ‘Keep the Core Clean’ would also mean less usage of SAP.