Many organisations are dealing with legacy ERP. The dependency on an ERP supplier can be such an obstacle that it takes away the necessary flexibility in the application landscape. According to Bert van Gestel, a layered approach can enable a transformation from the traditional role of the ERP supplier as a strategic automation partner to a software supplier or system integrator with branch expertise.
Written by Bert van Gestel, Schouw Informatisering | Source: AG Connect
Every day entrepreneurs compete in a volatile, complex and ambiguous world full of uncertainties. It is essential to be able to navigate and react quickly in this world. As a designer in your organisation you will therefore need to implement competent "manoeuvrability" in your company. This can be achieved with a concoction of vision, quality assurance, agility and a comprehensive understanding of your domain.
Reflecting on the current state of your organisation results in an overview of elements that hinder this manoeuvrability. The way the legacy business applications are organised currently has become a huge tangle that needs to be sorted. It is time to bring some manoeuvrability in your application landscape and end your dependency on your ERP supplier.
Legacy ERP is anything but flexible. Adjustments are costly, because it has become a complex matter to estimate the impact versus the risk of the adjustment. In addition, you are now caught in a vendor lock-in because the resources necessary for the adjustments are scarce. Moreover, since the adjustment requires the involvement of many parties, the lead time is often a matter of months rather than days. Throughout the years, ERP has become unique with its customised products, leaving it unsuited for the upgrade processes of the supplier. In fact, you are often worse off in terms of functionality.
A logical response is to prevent the above-mentioned drawbacks from recurring. The scarcity of resources and the corresponding price tag can be countered by low-code platforms that promise that anyone can adjust and expand their application. Vendor lock-ins are countered by selecting different suppliers for different applications. The customised product then becomes taboo and everything has to be standardised off-the-shelf software.
However, you can ask yourself whether this is tackling the root or treating the symptoms and whether you are actually moving towards the design requirements of a flexible organisation.
Around 2013 the agile way of thinking was boosted when Jeff Sutherland and Ken Schwaber published 'Agile Project Management with Scrum'. The central question of 'How can I plan in an environment with many uncertainties and progressive insight?' illustrated the power struggle between predictability and flexibility. At first sight, these two are mutually exclusive; any step towards increased project predictability compromises its flexibility. Their answer to this question is simple: in the short term, you optimise for predictability and in the long term you optimise for flexibility. By adding the dimension of time to the stalemate, the solution became obvious.
Nowadays a new question arises: how do I create a flexible yet reliable application landscape that enhances the possibility to innovate and quickly respond to market changes? The elements of predictability and flexibility arise here too, a seemingly irreconcilable duo. The ultimate aim is that the business administration goes smooth and follows a predictable path. However, the organisation needs a certain flexibility or room to manoeuvre to be able to innovate and respond. If there is no room for change, change will never happen. The lesson about agile project management revealed the first clue about how to navigate through this force field. An additional dimension is necessary.
The new dimension is the rate of change. You can introduce this by designing your IT with several layers. Each layer has its own rules around governance and its own rate at which changes are implemented. In his 2016 publication 'Pace-Layered Application Strategy and IT Organizational Design: How to Structure the Application Team for Success' , Gartner explains:
The communication layer is the key to 'loosely linked' applications. In the world of business software integration, it is all about securing processes that run over applications. A notification-based approach similar to how you would design the communication between departments and individuals provides the most flexibility.
Throughout the centuries business organisations have divided responsibilities over different departments, employees and departments have a mailbox at their desk and memos containing assignments or notifications have been dispersed. As an employee, it is your task to process everything in your mailbox that lies within your responsibilities and carry out the corresponding procedures. The reasons why this approach is so successful are the scalability and resilience of the system. The system continues to work if even if the number of notifications doubles or if a department changes its internal structure. This classic model also happens to be very successful as a model for modern system integration.
To make the application landscape manageable, you divide it into domains. A domain contains one application or a collection of applications that collectively form a whole. Think of the domain finance or the domain e-commerce. The domains often reflect the corporate structure. The various domains are related and therefore integrated. To enable this integration, every domain should offer a set of notifications:
By standardising these notifications in the communication layer you know which functionality to expect from each domain. You are now also able to adjust the application within a domain. As long as you respect the integration notifications, all your integrations remain operational. This is the manoeuvrability we seek.
If you adopt this approach, it replaces the traditional ERP supplier that tries to capture your entire company in one application. You will start to build business automation with the optimal combination of applications and a partner to assist with the integration.
The various application suppliers will implement the internals of the domains. However, finding a system integrator can be challenging. Most system integrators are highly technical and have little experience with specific business procedures. They will consult the process knowledge within the organisation to design the integration.
Standardisation of your integration notifications and processes that run over applications for specific branches is the new business opportunity on the market for business automation. Particularly, it offers an opportunity for the traditional ERP suppliers with an abundance of branch-specific process knowledge.
But what about the initial question of 'How do I get rid of my ERP supplier?' For those who follow the proposed strategy, the ERP application is merely an application for standardised processes with a wide range of integration possibilities. This leads to a drastic change for the traditional ERP supplier. They will go from strategic automation partner to software supplier or system integrator with branch-specific knowledge.
The latter will need to apply their comprehensive knowledge of the business processes of their clients to help them in the transition towards a flexible model for computerisation. In addition, they will need to further develop their data competencies (low code, AI, ML, BI) and help clients with innovation and differentiation.