How do you choose an ERP for a school?

What should you evaluate first?

Most school ERP evaluations start with a feature matrix, and feature matrices are where every product looks identical. Every one of them ticks admissions, attendance, fees, examinations, and a parent app. The differences that decide whether the rollout succeeds are two levels below that.

A better method: pick the single workflow that currently consumes the most administrative time — for most institutions it is fee collection with its concessions, instalments, late fees, and refunds — and ask each vendor to demonstrate it with your rules, on your fee structure, using your edge cases. Not a generic demo.

The vendors whose product genuinely fits will do this in the meeting. The ones who need to 'take it back to the team' are telling you the answer is customisation, which is the answer you most need to hear before signing.

Which requirements are usually underestimated?

These are the ones that surface in month four of a rollout, when changing vendor is no longer realistic.

• Fee concessions and their approval chain — sibling discounts, staff wards, scholarships, partial waivers, and who is allowed to authorise each. This is where a generic fee module usually breaks first.
• Mid-session changes — a student changing section, stream, or transport route in October, and what that does to fees already raised.
• The academic calendar — terms, house systems, electives, and combined-section subjects rarely match the product's assumptions.
• Report formats — board, university, or affiliating-body formats are non-negotiable and specific. A configurable report builder is not the same as a report that already matches the format.
• Parent adoption — an ERP whose parent app is unused becomes an ERP whose data is stale, because parents fall back to calling the office and the office falls back to a register.
• Teacher time — if marking attendance takes ninety seconds instead of fifteen, teachers will batch it at the end of the week and the attendance data becomes fiction.

Should you buy a product or build a custom system?

What questions should you ask every vendor?

Ask these in writing, and keep the answers. Half of them are about the end of the relationship, which is exactly when nobody is willing to renegotiate.

• Can we export every record — students, fees, attendance, marks — in a documented format, on demand, without a support ticket? What does that cost?
• Who owns the data, in the contract's own words?
• What is the support response time during fee-collection week and at result declaration, and is that in the agreement or in a brochure?
• How many institutions of our size and board are live on this today, and may we speak to two of them without you present?
• What does the price look like in year three, and what governs the increase?
• When a statutory or board requirement changes, is that an included update or a change request?
• What happens to our data and our access if we do not renew?

How should the rollout be sequenced?

Almost every failed school ERP rollout attempted every module in one session. The sessions that succeed go module by module, in the order that makes the next one easier.

Start with student records and admissions, because everything downstream keys off a clean student master. Then fees, which is where the value is most visible to management and where a working system builds the political capital for the rest. Then attendance and examinations, which touch the most staff and therefore need the most training. Parent-facing features last, once the data behind them is trustworthy — a parent app showing wrong information is worse than no parent app.

Run the changeover at the session boundary, never mid-term, and keep the old system readable but not writable for one full cycle. The cost of that overlap is small; the cost of discovering a gap with no fallback is not.