No Code Programming Sap Erp [shutterstock: 1451794184, Roman Samborskyi]
[shutterstock: 1451794184, Roman Samborskyi]
Blog SOH and S/4

No-Code Programming Will Kill Parts Of SAP ERP

Stripping away all marketing noise, what is an ERP system? A database storing the various documents and states; business logic with APIs; and a set of screens interacting with the business logic. If all or most can be created without the need of any programming, then what is left 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…

ad_banner

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.

Image provided by author.
Image provided by author.

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.

About the author

Werner Daehn, rtdi.io

Werner Daehn, former SAP employee, is an expert on big data and smart data integration. He is also the CEO of rtdi.io.

2 Comments

Click here to post a comment

  • This is an informative post. Got a lot of info and details from here. Thank you for sharing this and looking forward to reading more of your post.

  • No code or low code looks and feels fancy but the truth is real coding will always be there. These tools are good for some stick to pattern mobile development efforts; a rough comparison would be the ABAP Query Tools that let anyone create a data model and a report in the ECC system. For core optimization and customization and real business tools real ABAP coding will always remain.

    I do agree some external stuff connected to the digital core like say IoT apps etc. can be shifted to low code, and I am sure many are already doing so. But that is not the real SAP – real SAP is in the ERP core.

    And keep the core clean – well you just got it all wrong and didn’t understand what it stands for like many. That is why we have extensions and an efficient Fiori based RAP and CAP model of programming.

Social Media

ad_banner
Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy. terms and conditions .


Our Authors