Will low-code/no-code drive (or fix) ERP technical debt?

A much better approach to the ERP ‘rip and replace’ is to appreciate the existing ERP’s strengths in terms of holding and processing critical data, while improving on its main weaknesses – they are expensive to run and make changes to. If we acknowledge this, low-code can contribute massively to stopping the creeping ERP technical debt.

By leveraging low-code, organisations can move from a traditional “everything is done on the ERP” mindset to a more agile approach. An approach in which the ERP holds the core data and ensures transactions are safe, but the business process and the apps people interact with are orchestrated in the low-code platform.

For example, the end-to-end process of customer onboarding, which involves a lot of coordination between people and systems, is not always straight forward when using an ERP. The user experiences they offer are often poor and unfit for the work at hand, they are also built to be used in isolation, so they tend to throw up challenges when it comes integrating with other systems in the organisation. Granted, given huge quantities of time and money, it’s not impossible for an ERP to achieve a solution to this, albeit one that would likely compromise the user experience. But it’s a whole lot easier for a low-code platform to achieve this – it’s what they are great at. They can pull data from one system to be validated, then pull more data from another system, combine it together and so on. And where changing one business rule to an ERP can take weeks or months of expensive consulting, release management and testing, these changes are made instantly available on a low-code platform. Ease of use and user experience are orders of magnitude better. This reduces pressure on the ERP, pauses technical debt growth and creates the opportunity for organisations to work on reducing it in a much more pragmatic and less risky way.

Because the ERP is like the heart of a business, replacing it or tampering with it, brings too much risk. Core systems migrations so often fail, and a better approach is to make these changes incrementally – start removing functionality from the ERP and start building it outside the ERP in a more distributed manor. When you start externalising functionalities and building out your technology landscape in a more distributed way, it becomes significantly easier to change different components without impacting the whole system.

However, there is an important and often overlooked catch – it’s very easy to use low-code to generate even more technical debt. If I were to buy a low-code platform for my organisation and just let people build a bunch of ungoverned, disconnected apps, it would generate more debt and scatter my data even more.

That is why fixing the ERP technical debt with low-code requires a truly strategic – meaning consistent, long term and governed – approach, ensuring the low-code solutions tap into the ERP data, while guiding people and other systems to collaborate on the execution of end-to-end business processes. As long as this is achieved, low-code offers an efficient, affordable and time sensitive solution to technical debt, something that I am already seeing an increasing number of businesses benefit from.