ERP Architecture – 2 fundamental cornerstones and 4 architypes to serve your business

1. Introduction

There are two fundamental cornerstones to ERP architecture:

• the business capability and process scope of your ERP
• the instance strategy of your ERP: single instance, or business division / geographical instances

The picture below highlights these two cornerstones. The vertical axis indicates how many business capabilities or processes the ERP solution covers, e.g., general ledger accounting, accounts receivables, sales order processing, available-to-promise check, installed base, service order. The horizontal axis indicates how many business divisions, legal companies, countries, and factories the ERP solution covers.

These dimensions need to be aligned with your business model and requirements. The next two chapters explain more details. Chapter 4 explains architypes for 4 different combinations of our dimensions.

At the end of the blog, we also highlight the importance of user experience. It is the capstone for a successful ERP journey based on our two fundamental cornerstones.

2. Business capability and process scope

ERP integrates logistics transactions to finance – this is the core of all ERPs systems, and we can say that this integration is what makes an IT system a true ERP system. This is illustrated in the picture below.

Why do we start from such a basic and fundamental topic? The reason is simple: to ensure that we understand the core of ERP, what capabilities and processes really belong to ERP – and what capabilities and processes have more flexibility in our ERP architecture. This is the area depicted in grey in the picture below.

Logistics and Finance transactions which are tightly connected to each other should be part of the ERP scope. Examples of these are illustrated in the picture above in the light red finance core and green logistics area surrounding it.

The grey area indicates business capabilities and processes which can be inside or outside of ERP. They do not directly create financial transaction, but they use data and “ERP documents” from the green area. The white area contains a few examples which normally are never inside ERP.

3. Instance strategy

Instance strategy is basically an easy topic – you just need to know if your business model is

• global – cross country borders, business divisions etc., or
• local – you locally manufacture products in one country and / or business division

Difficulty arises because business often contains both models. And changes to the business model, or underlaying ERP architecture, are difficult to make. Both the business model and ERP architecture are strategic and fundamental cornerstones.

In a global multi-leg supply chain, most transactions, both logistics and financial, are internal to your enterprise. In these cases, single instance global ERP can provide the needed transparency and efficiency to your enterprise.

A single-leg supply chain consists mainly of local transactions between your enterprise, or even a local unit of it, and your business partners. A local ERP instance strategy can bring flexibility and agility to your local business units’ requirements.

The supply chain model is not the only aspect we need to consider. Also, legal structure, ownership of legal units, and future plans need to be taken into account. The table below summarises aspects to be considered for ERP instance strategy.

4. Architecture architypes

Business divisions specific / local ERPs work well when this approach is aligned with your business model and structure described in chapter 3. This approach also allows wide functional scope inside your ERP, because each ERP is a smaller business division / site scope dimension. This architecture requires well working centralized financial consolidation or “central finance” capability.

There are several ERP products on the market for this architecture approach, both from global IT vendors and more regional IT vendors.

Local best of breed architecture often leads to shared finance solution, with home-made integrations. Based on our definition in the beginning, this is not a real ERP system. This architecture works for organisations that do not need traditional ERP. Traditional ERP is very useful for organisations with physical (not digital) products, supply chain and production. If your organisation is pure digital, then this architecture might work for you.

Single instance ERP with wide functional coverage is challenging to implement and run. Some large enterprises have managed to implement this architecture and they are enjoying benefits of single instance ERP. However, many of them have paid a large amount of customisation, even own code, as a penalty of this approach. We see a tendency to simplify large ERP solutions and go towards standard functionality. Often this also means reduced functional scope of the ERP. In this case more and more business capabilities and processes are implemented outside of the ERP.

Only a few ERP vendors can provide a scalable and well working solution for this architecture architype.

Lean single instance ERP is attractive for many organisations. This approach brings benefits from global transparency, both from a logistics and financial point of view, and allows business / local variation outside of the ERP. The key to success is defining your core ERP functionality as described in chapter 2 and main integration to outside ERP solutions. APIs and well-defined integration architecture are technical cornerstones in this architecture architype.

The picture below summarises our 4 ERP architecture architypes. We at Tietoevry have experience from all these architypes. Contact us for assessment of your current ERP architecture, and more importantly to analyse your business requirements and design future ERP architecture.

5. User Experience – capstone for successful ERP architecture

The right ERP architecture is not enough. On top of your ERP system(s), superior user experience is needed. Please read about Headless SAP  – how to make a superior user experience on top of SAP ERP or S/4HANA.