What an ERP actually is, and four tests to run on yours

Ask three people in the same company what last month’s sales were and you get three figures. The accountant reads the posted invoices, the sales manager reads his own spreadsheet, the warehouse reads what left the door. All three are honest. All three are working from a different record. That gap is the entire problem an ERP exists to close, and it is the only definition of the term worth carrying into a vendor meeting.

An ERP is a database, not a program

The word is sold as a product category. It is closer to an architectural decision: one set of records that every department writes into, rather than one file per department that somebody reconciles afterwards.

The consequence is what matters. When a warehouse clerk receives 200 cartons against a purchase order, four things happen in the same instant on a real ERP. Stock on hand rises by 200. A liability to the supplier is recorded. The cost of those cartons enters inventory valuation. The buyer’s open purchase order closes. Nobody typed four times, and there is no version of the truth in which three of those happened and one did not.

On a set of connected programs, those four happen in four places, at four different times, entered by two or three people. The reconciliation between them is a job somebody holds down full time. That job is the cost you are trying to remove.

Four tests

Run these against what you have now. They take an afternoon and they settle the question faster than any demo.

1. The same-number test. Pick one figure that finance, sales and operations all care about. Last month’s revenue works. Ask each of the three to produce it without talking to the others. If the three numbers differ by more than rounding, you have three systems wearing one name.

2. The single-entry test. Follow one supplier invoice from the day it arrives to the day it is paid. Count how many times a human keys the same amount. On a real ERP the answer is one. Three or more means the connections between your modules are people.

3. The absent-person test. Name the file that runs a critical process and the person who owns it. If that person is on leave for two weeks and the process stops, the process lives in a spreadsheet, not in a system. Most companies I have worked with in the UAE, Saudi Arabia and Egypt can name that file inside thirty seconds, which tells you how well known the problem already is.

4. The new-branch test. Ask what has to be built before a second branch or a second legal entity could open next quarter. If the answer includes copying a workbook and renaming it, growth is going to cost you a headcount rather than a configuration change.

Failing one of the four is normal. Failing three means the question is no longer whether to buy a system but which one, and the systems comparison is where that starts.

What is actually inside one

Three parts, and a system missing any of them is being sold to you under the wrong name.

The financial core. Not invoice recording. The general ledger, sub-ledgers for receivables and payables, fixed assets and depreciation, and the automatic postings that tie a goods receipt or a delivery note to a journal entry without anyone writing it. If a system asks the accountant to post the inventory movement by hand, the financial core is missing.

The supply chain. Purchase requisition, order, receipt, invoice matching, storage, picking, delivery. The test of depth here is a forward-looking one: a real supply chain module tells you when to reorder, from consumption rate and lead time, not only how many units are on the shelf today. Reorder rules are the line between an inventory list and inventory management.

Customer and people records. The sales pipeline attached to the same customer record the invoice is raised against, and employee records attached to the payroll postings that hit the ledger. Both are commonly sold as separate products, which is where most of the confusion about the term comes from. The difference between ERP, CRM, MRP and WMS is worth twenty minutes before any vendor conversation, because three of those four names describe chapters of the fourth.

Beyond those three, everything is a decision rather than a requirement. Which modules earn their place, and the order to switch them on in, is a separate question with a longer answer.

Cloud or on-premise

The honest version of this comparison is short.

Cloud removes the server, the backup regime and the upgrade project. You rent, the vendor patches, and a new user is a line on next month’s bill. The cost is control: the customisation surface is narrower by design, and your data sits in a region the vendor chose. For a company under roughly 100 users with no unusual regulatory constraint, this is the default and arguing otherwise usually costs money for no return.

On-premise buys two things. Full control of where the data physically sits, which some government and defence contracts require in writing. And deep customisation, meaning modification of the application itself rather than configuration of it. The second is a trap as often as it is a benefit, because a heavily modified system is a system that cannot take the vendor’s next release.

The deciding question is not size. It is whether you can name a specific written requirement — a clause in a contract, a regulator’s rule — that the cloud edition fails. If you cannot name it, you do not have it.

The five phases

Implementations that go wrong nearly always went wrong by skipping one of these, and it is almost always the third.

1. Discovery. Map the process as it runs today, including the parts that embarrass people. The output is a document naming each step, its owner and its current failure rate. Automating a broken process produces a faster broken process.

2. Solution design. Decide how the system will handle each mapped step, and write down which steps will change to fit the software. That second list is the one nobody wants to make and the one that decides the project.

3. Data migration. Item master, customers, suppliers, opening balances. This is the phase that gets compressed when the schedule slips, and compressing it is how a go-live turns into a rollback. It has its own article for a reason.

4. User acceptance testing. Real scenarios run by the people who will do the work, against migrated data, with a written pass or fail per scenario. A demo by the implementer is not UAT.

5. Go-live and hypercare. Cutover, then a defined support period at higher intensity. What happens on go-live night is a schedule, not an event.

Three signs to stop and reassess

From the implementer’s side of the table, these three predict trouble months in advance.

They agree to every customisation without pushback. A vendor who never says “the standard process handles this, and here is how” is optimising for the signature, not for your third year. Every modification is a cost you pay again at every upgrade.

They never ask you to name an internal project owner. An implementation needs somebody inside the company with the authority to decide that a department will change how it works. If nobody asks for that person, nobody expects those decisions to be made.

Training is about buttons. “Click here to raise an invoice” is not training. “Here is the order-to-cash cycle, here is where your job sits in it, here is what breaks downstream if you skip this field” is. The first produces users who cannot recover from an exception; the second produces people who can.

Seven distinct causes account for most of the failures I have seen, and four of them are management decisions taken before the software was chosen. They are set out in why ERP projects fail.

Where to go from here

If you are learning the field rather than buying, the reading order starts with the four business cycles and takes about a week. If you are choosing a system, start from the comparison table and treat the vendor demo as an examination you set rather than a presentation you attend. How to read a demo covers the eight questions that expose a product’s real limit inside forty minutes.