When a school migrates to a new ERP and three months later the staff is still using spreadsheets for half the workflows, the natural assumption is that the software is bad. Sometimes it is. More often, what failed isn’t the product — it’s the institution’s adoption discipline. Modern ERPs are configurable, capable, and well-documented. They will sit unused all the same if no one inside the institution owns the relationship.
Across institutions that get real value from their school management software, we see three operational habits show up again and again. None of them require a budget, a consultant, or a technology background. They require a small amount of organisational discipline.
Habit 1: Designate one administrator as the platform champion
The most reliable predictor of successful ERP adoption isn’t the size of the institution or the technical sophistication of the staff. It’s whether one named person inside the institution owns the platform.
This person is not the most senior administrator. They’re not the IT contact. They’re the person who knows how the institution actually runs day-to-day — usually a senior office administrator, an academic coordinator, or a section head. They understand which processes are formal and which are informal. They know who actually needs which permission. They know which workflows can be standardised and which need to stay flexible.
What changes when you have a champion is concrete:
- Configuration questions get answered the same week, not the same quarter.
- Staff who get stuck have a single person to ask, instead of “I think IT handles that?”
- Vendor support requests go out with full context, so resolution is faster.
- New features get evaluated and either rolled out or consciously deferred — instead of accumulating as unused capability.
The champion needs two things from leadership: dedicated time (one to two hours a week, even at steady-state) and decision authority (they can approve workflow changes, configure roles, and add fields without escalating each one). Without both, the role is decorative.
Habit 2: Configure for your actual workflows, not the vendor’s defaults
Every modern ERP ships with sensible defaults. The defaults reflect the average institution the vendor has seen. Your institution is not the average institution. Whatever makes your institution distinct — your fee structure, your attendance policy, your admissions process, your academic calendar — these are exactly the things the defaults will get wrong.
Most schools accept the defaults because customisation feels intimidating. The vendor’s training doesn’t emphasise it; the staff doesn’t know what’s possible; the result is that the institution moulds itself to the software instead of the reverse.
This is backwards. The institution existed before the software. Its workflows have been refined over years and reflect real constraints — regulatory, cultural, operational. When you accept the defaults, you’re either changing those workflows (with all the friction that implies) or quietly working around the software (with all the inefficiency that implies).
The right move on day one of adoption is to spend a week mapping each of your major workflows to the platform. Where the platform fits cleanly, accept the default. Where it doesn’t, configure: custom fields, custom statuses, role-specific dashboards, automation rules. Most modern ERPs support far more configuration than the introductory training reveals. Use it.
A practical heuristic: if a staff member has to write something on paper because the system doesn’t capture it, configure the system. If a workflow has an exception that runs through someone’s WhatsApp, configure the system. If a report has to be assembled by hand from three exports, configure the system.
Habit 3: Schedule a quarterly platform review
The institution that adopted a tool eighteen months ago is not the same institution today. New programmes have been added. Compliance requirements have shifted. Staff has turned over. The configuration that worked at adoption is probably not the configuration that fits now.
Most institutions never revisit this. The platform settles into a steady state at month three or four, and the configuration is treated as immutable for the next several years. New workflows get added in spreadsheets and parallel tools, layered on top of an ERP that should have absorbed them.
A quarterly platform review fixes this. The format is simple: the platform champion, one academic representative, one administrative representative, and the head of finance sit for an hour. They look at three things:
- What’s used. Which modules and reports are actually being accessed? The vendor’s analytics will show you. If a feature isn’t being used, either it’s badly configured, badly trained on, or genuinely unnecessary. Decide which.
- What’s ignored. Which workflows are happening outside the platform? WhatsApp groups, Excel files, paper registers. Each one is a signal that something needs configuration, training, or — sometimes — a feature request to the vendor.
- What needs reconfiguration. New programmes, new fee categories, new reporting requirements. These accumulate quietly. The quarterly review surfaces them before they become emergencies.
An hour every three months. Most institutions don’t spend it. The ones that do are the ones whose ERP investment compounds rather than depreciates.
What ties these together
None of these habits are about the software. They’re about whether your institution treats the platform as something it owns or something it tolerates. Software adoption is, in the end, an organisational behaviour. The tool is a force multiplier for the discipline you already have. If the discipline isn’t there, no amount of feature-richness will compensate.
The good news: the discipline is cheap to build. One named champion, one mapping exercise, one quarterly hour. That’s almost the whole formula.