ERP systems are often built using what’s called a three tier layer design consisting of ;
The Database Layer
Application Layer
Presentation Layer
The top layer is the Presentation Layer. This is the ‘public face’ of the ERP system. It’s the way you, the user, interact with the system. Traditionally the Presentation Layer was software that sat on your individual device, your laptop or desktop.
However, with the evolution of cloud ERP it’s now possible to access the ERP system using Chrome or Safari. This means you don’t have to have the software GUI (this stands for Graphical User Interface and is pronounced ‘gooey’) installed on your device.
The presentation layer “sits” on the Application Layer. This is the software that actually runs all the business processes, processes the transactions and runs jobs in the background. This layer contains what is called the Database Management System (DBMS) which is the software that is used to access the data which is held in the Database Layer.
The final layer is the Database Layer. The database layer is where all the data is actually stored.
The database can be located on servers owned or leased by the business but increasingly, they are held in the cloud.
The data is retrieved by the Application Layer for processing (via the database management system).
We mentioned cloud when we were introducing ERP.
‘The Cloud’ is where the data is stored by third-parties (or cloud vendors) who provide the data storage access via the internet so that you don’t need large on site servers to store the data.
In the same way that you can access your music or videos on iCloud or Google Drive from your phone or laptop, so users can access large ERP databases.
A great example of a cloud vendor is Amazon who, as well as being able to sell anything from mobile phones to groceries, can provide ‘pay as you go’ computing platforms. This is done through their AWS (Amazon Web Services) arm. Cloud costs depend on how often you access your data and the amount of data that is stored.
Cloud solutions are generally cheaper as there is no need for the system owner to buy and maintain the hardware, the buildings or the staff that were traditionally required to run an ERP.
A database is an organised set of information or data that is saved in a structure similar to a spreadsheet.
We can imagine an excel spreadsheet as a database in its most simple form.
Spreadsheets however are not suitable for large scale operations and are only designed for a few users.
Databases are scalable and access can be made by many users in parallel. Databases generally are not accessed directly. They are accessed via the Application Layer in order to maintain integrity of the data and to allow access to be controlled for performance and security reasons.
In order to manage the data, a database will require software.
The combination of the database coupled together with the management software is referred to as a Database management system (DBMS).
There are many different types of databases that are used for different purposes, depending on the data that is being held and the way the data needs to be retrieved.
The two main types of database used for storing all data related to business processes are relational and object-oriented databases. A relational database is where the data is stored in the forms of tables that have indexes which link them to each other.
Microsoft SQL and Oracle SQL databases are examples.
An object-oriented database is where the data is stored as objects and each object has a set of attributes and methods that decide what is done with the data.
An object database stores complex data and relationships between data directly, without mapping to relational rows and columns, and this makes them suitable for applications dealing with very complex data.
PostgreSQL database is an example of an object-oriented database.
The top database software tools in 2020 were;
Microsoft SQL Server
IBM Db2
Knack
PostgreSQL
Google Cloud BigTable
MySQL
MongoDB
SAP HANA
TeamDesk
Amazon RDS
You’ll notice that some of those databases are sold by vendors who also sell application software, so they are designed to complement the Application Software offerings that the same vendors sell. By doing this, vendors are able to sell “the full package” to customers tying them into secure relationships.
Some organisations choose to mix and match database vendors with ERP vendors. Historically for example an organisation may have in-house database experts for one particular brand but then choose to replace their application software. It was common for SAP application software to use an Oracle database until maybe the last ten years or so.
SAP HANA databases were introduced in 2011 so SAP now offers the entire end to end solution (Database, Application Software and Interface) for users, a one-stop shop for ERP.
Over the years ERP systems have evolved and been built to satisfy industry standard business processes. These standard business processes have been built and developed based on industry best practice and are continually enhanced to meet the ever changing requirements of the business world.
Each ERP system is delivered with a set of “out of the box” standard business processes which have been built using the ERP systems native programming code.
These ‘out of the box’ standard ‘vanilla’ best practice processes are delivered as part of the base ERP product.
The ERP system can be personalised to an individual customer by making some standard system settings or parameter changes.
This can range from setting a flag to defining a set of business rules.
This is known as configuration. These configuration settings enable the customer to personalise the product without changing the underlying code.
Once the ERP system has been configured then the standard business processes can be easily accessed by the customer.
What if the standard business processes delivered with your ERP system don’t fit your business needs?
Maybe the standard process works slightly differently to the way you carry out the process today, or you have a unique process that isn’t covered by the standard process at all.
Then you’ve got a decision to make, do you change your business process to fit the standard process or do you change the source ERP code to make it work for your business?
This is known as customisation or development, and involves expert technical developers enhancing the core ERP software to work as per your business specific requirements. This might be a report or an interface between your ERP system and another application.
We’ll cover more on configuration and customisation later. Your business processes are not static, they need to change over time to survive in the marketplace.
Keeping it standard and going with ‘out of the box’ standard business processes and standard configuration not only helps to keep down your ERP project implementation costs but also your longer term ERP maintenance costs. Every piece of customisation and development costs money and the more you customise and develop your ERP system the more expensive it becomes, that’s a fact. And be aware customisation doesn’t come cheap either.
Hopefully if you’ve done the right level of due diligence and been thorough in the evaluation of your ERP product, you’ll have selected the right package for you. Fingers crossed this means that you’ll have selected the ERP software vendor that most fits your business need with minimal customisation.
That’s easy to say. In reality, the chances are you’re going to need some level of customisation of your ERP system.
Very few organisations manage to go with a completely ‘out of the box’ solution with zero customisation or development.
The key to success is to control, manage and minimise the customisation that you do.
Every piece of customisation you do will cost you initially to implement.
There is also an ongoing maintenance cost that you will need to factor in.
If the business requirements change then the customisation might need to change. You also need to consider changes or upgrades to the ERP software which might invalidate your development.
There should be a valid business reason for doing any piece of customisation to evaluate whether it’s really required.
You’ll more than likely have a limited budget for implementing your ERP solution so if you approved a 10 day piece of customisation that wasn’t within the original plan, what else might not get done? Something else might have to give, you might need to prioritise.
Challenge the business, is there really a requirement, could the requirement for customisation be negated by them changing the way in which they work.
We’ve already discussed some of the core business processes that all organisations do - buying stuff, selling stuff, recording transactions and reporting. These are processes that are the mainstays of running the business. They generate no competitive advantage so why would we spend money on customising them?
The advice… always start your ERP journey with a mindset of ‘keep it standard’ then evaluate your ‘unique’ business practices on an individual basis to determine the cost and benefits of each proposed customisation and determine whether it’s valid.
Any customisation that’s done should drive added value within the business, don’t just customise for the sake of it.
When we are implementing an ERP solution it’s good practice to first build a prototype, to check and validate whether the solution is fit for purpose. Once agreed, then scale it and finally deploy the changes to the productive environment.
When we talk about ERP we often refer to the ERP landscape, this refers to the arrangement of the ERP servers needed to deliver your solution.
Typically an ERP Landscape will be a minimum of a three system landscape consisting of a Development Server (Dev), a Test or Quality Assurance Server (QAS) and a Live Production Server (Prd).
The Development and Test servers are used through the duration of the ERP implementation to build and validate the ERP solution. Once the ERP solution ‘goes live’ then the Live Production server will be used by the business to process actual everyday business transactions.
Before we start defining our ERP solution, we need to establish what the business needs the ERP solution to be able to do. We need to understand the business system requirements.
System requirements are gathered through sessions with the business.
We need to understand the scope of what the business needs the ERP solution to do and any business specific or industry specific nuances that we need to consider.
Once we’ve gathered the business requirements and agreed the scope of the solution, we can start to build the first system prototype. This basic functionality is built in the Development Environment.
Once the ERP consultants are sure that the system changes they’ve made satisfy the business requirements identified, they move the changes to the test and quality assurance environment.
This is the environment where the business users will test and validate the changes to ensure they are fit for purpose.
The business uses this environment to simulate transactions that would normally take place in the Live Environment.
Ideally the business will test and validate every business scenario that will be undertaken, including the anomalies and unusual transactions.
The business needs to be sure that the ERP solution delivers what they need it to, so that when it ‘goes live’ and the business starts to actively use it they will be able to carry out their daily activities. They will be able to fulfill sales orders, pay suppliers and receive customer payments.
The business users will sign off and approve changes that will move to the Live Environment.
The Live Production Environment is the environment our business users utilise to process the real day to day business transactions, it’s our golden client that contains all our data.
Best practice landscape management dictates that changes (configuration and code) are only made in the Development environment, it should not be possible to make changes directly in test or live environments.
Changes have to first of all be made in the development environment then those changes are moved to the test environment and when successfully tested to the Live environment.
This approach aims to ensure the integrity of the ERP solution in Test and Live Production environment. Maintaining a consistent and integral landscape.
It also ensures that system changes are tested and signed off before they are deployed into the live Production environment, minimising the risk of introducing change.
If changes were allowed to be made directly in the live environment for example, this would lead to all the environments quickly becoming out of sync. If that happens then the development and test environments will become pointless.
Worse still, if system changes are made directly in the live environment, it may well result in our actual transactional data becoming corrupt due to changes that have not undergone the right level of due diligence.
Other technical environments may exist in your ERP Landscape.
These are usually created for specific projects that are running in parallel to the system that is supporting the day to day business. They are sometimes referred to as project tracks or project environments.
The dictionary definition of Analytics is the systematic computational analysis of data or statistics. Analytics are used for the discovery, interpretation, and communication of meaningful patterns in data.
Organisations may apply analytics to business data to describe, predict, and improve business performance.
What’s happened in your business?
Why’s it happening?
What’s likely to happen in the future?
What does the organisation need to do?
There are many different types of analytics that a business can employ to give them better insight. It’s a complicated area though and the organisation needs to weigh up the value the analytics can bring versus the complexity of implementing it.
Since analytics require extensive computation, the algorithms and software used require the most current methods in science, statistics, and mathematics.
When we speak about ERP, it’s usually not just one system, it’s a collection of systems that are linked together via integration. Integration is the term used to bring together different systems, to enable them to act as one large co-ordinated entity that delivers the business processes.
The primary reason to integrate systems is to enable automated data transfer, which will lead to fewer manual errors and speeding up applications. In order to build integration between systems it is common for Integration Architects to be employed, who will design and build what are called Integration Layers into the ERP Landscape.
In the world of IT, GRC stands for Governance, Risk, Compliance and Cybersecurity.
These are the four key activities that an organisation must carry out in order to ensure that it is successfully achieving its objectives, acting on uncertainty and acting with integrity.
Computer security, cybersecurity or IT security is the process of protecting computer systems and networks from theft or malicious damage.
This could include damage to hardware, software or data, sometimes referred to as hacking.
With the advent of the “Internet of Things” (or IoT), which is the accumulation of computer systems, devices, smartphones, other smart devices such as TVs, and bluetooth and wireless communications, there is more reason than ever why we need to protect all these devices from cyber attack.
Because of the number of systems that are available now for use, it is necessary to protect these systems from attack.
When systems are attacked, this leads to security breaches.
Security breaches need to be minimised and in order to do this, security measures are put in place that will either detect or prevent security breaches.
Security measures can include such things as;
User access
Firewalls
Intrusion detection systems
Security breach Response measures
Software is available to maintain security and there are vendors who specifically sell security software.
GRC can also be a component of an ERP system, that helps to run the processes required to control access and reduce risk within that system.
GRC is normally broken down into these modules
Access Control
Process Control
Risk Management
Environment, Health and Safety
Let’s discuss each of these modules in the context of what they are.
ERP access control prevents and identifies access and authorisation risks in ERP systems that prevents fraud, and also helps to reduce the cost of continuous compliance and control.
Access control aims to be compliant with Sarbanes-Oxley (SOX) and other laws and compliance rules. Access control includes further access requirements such as emergency access requests and audibility and other access requests such as remote access.
Process Control is the software application that focuses resources on high impact processes, regulations, and risks. It gives the possibility of continuous monitoring of control simultaneously improving compliance and efficiency of business process quality at the right cost.
The module normally includes a repository that allows you to store all the documentation relating to policies, procedures and legal regulations applicable to the business requirements. The documents that are stored in the repository are linked to the business activities.
If there are changes in business activities then alerts can be created to update documentation.
Risk Management is the application that will allow you to record and track risks associated with the business processes.
There are options such as workflow that can be enabled that will allow users to be notified if risks need action.
There are many policies, procedures and specific requirements that are needed in order to maintain control. Modules are available that will store essential health and safety documentation and link to the business processes.
Find out how you run an ERP project.