An ERP project succeeds or fails on its requirements. Write a clear Business Requirements Document first, and sort every need into Standard, Configuration or Customisation before you talk to vendors.
- Write down how your business works before you evaluate any ERP.
- A Business Requirements Document (BRD) is the single most useful document in an ERP project.
- Classify each requirement as Standard, Configuration or Customisation.
- Customisation is where cost, time and risk hide — keep it intentional.
- A clear BRD lets you compare consultants and quotes fairly.
Most business owners start an ERP journey the same way: they ask a few people which software is good, watch two or three demos, and pick the one that feels right.
Then the real work begins — and so do the surprises. Features that looked standard turn out to need customisation. Timelines stretch. Costs grow. Everyone is frustrated, and nobody can quite say where it went wrong.
It usually went wrong at the very beginning: nobody wrote down how the business actually works.
Start with the business, not the software
An ERP is a mirror of your operations. If you can't describe your operations clearly, no ERP can mirror them.
Before any demo, sit down and answer plain questions:
- How does an order come in, and who approves it?
- How do you buy, and who decides from whom?
- How is stock tracked, and where does it go wrong today?
- What does your accountant need at month-end that takes too long?
- Which reports do you actually look at — and which do you wish you had?
Those answers, organised properly, become a Business Requirements Document (BRD).
Why the BRD matters more than the demo
A demo shows you what the software can do. A BRD shows you what your business needs it to do. Only one of those is about you.
A good BRD gives you three things:
- Clarity — everyone (owner, team, consultant) is reading the same description of the business.
- Comparability — you can give the same document to several consultants and compare their quotes fairly.
- Control — scope creep becomes visible, because every new request can be checked against what was written.
Standard, Configuration or Customisation
This is the most useful habit I know in ERP work. For every single requirement, ask which bucket it falls into:
| Bucket | What it means | Cost & risk |
|---|---|---|
| Standard | The ERP does it out of the box | Lowest |
| Configuration | The ERP can do it with settings, fields, workflows or formats | Low to medium |
| Customisation | New code has to be written | Highest — now and at every upgrade |
Customisation isn't bad. But it should always be a decision, not an accident. When you can see how many requirements sit in that last column, you can have an honest conversation about whether the business should adapt the process or the software should adapt to the business.
Why I built ERPBlueprint
I saw this problem so often that it became a product. ERPBlueprint — part of The Tiny Apps Company — asks business owners plain questions about how they operate and turns the answers into a clear BRD for ERPNext, with every requirement classified as Standard, Configuration or Customisation.
It doesn't replace good consultants. It makes the first conversation with them far better.
The takeaway
Don't start with "Which ERP should we buy?" Start with "Can we describe how our business actually works?"
Once that is written down, choosing the software — and the people to implement it — becomes a much simpler decision.
Frequently asked questions
What is a BRD in an ERP project?
What is the difference between configuration and customisation?
How long should writing requirements take?
Is there a tool that helps write an ERPNext BRD?
Mayank Kariya
Business and technology thinker. Director at Reformiqo Business Services, founder of The Tiny Apps Company (SpacePartner, ERPBlueprint) and author. He makes complex things simpler. More about Mayank