SCHOOL MANAGEMENT · PROCUREMENT AND GOVERNANCE
How to Create a School ERP Requirements Document Before Talking to Vendors
A structured way to record school workflows, users, controls, reports, implementation needs and evaluation evidence before vendor selection.
Conceptual product view · no customer records or performance figures
THE SHORT ANSWER
A useful school ERP requirements document explains the school’s priority outcomes, current workflows, user roles, data and reporting needs, controls, implementation constraints and acceptance tests. Distinguish mandatory needs from preferences and ask vendors to classify each response as demonstrated, configured, manual, planned or unsupported.
01 / OUTCOMES & CONTEXT
Describe why the school is considering a new system.
Summarise the institution, its operating model and the problems that matter most. Use measurable statements where practical: reduce reconciliation effort, make a defined report easier to prepare or clarify record ownership.
Avoid starting with a preferred vendor’s module list. Outcomes give providers a common context and help the school distinguish essential requirements from interesting extras.
02 / WORKFLOW REQUIREMENTS
Describe tasks, roles, exceptions and hand-offs in plain language.
For each priority process, record who begins the work, what information is needed, who reviews it, what happens next and how exceptions are handled. Include common and high-impact edge cases.
State whether a requirement is mandatory, desirable or outside the current phase. A process diagram or scenario can help vendors respond without interpreting a vague feature label.
03 / DATA, REPORTS & CONTROLS
Specify fields, access expectations and the decisions a report should support.
Identify the minimum information required, its source and the roles that may view, change or export it. Note any history or approval need and ask vendors to demonstrate those controls.
Define each important report question, period, filter and interpretation. Do not request a chart without explaining the management decision it should inform.
04 / DELIVERY & OPERATING CONDITIONS
Record migration, training, devices, connectivity and support assumptions.
Describe data sources, expected cleanup, user groups, locations, connectivity constraints and the school’s available project time. Ask vendors to state what they provide and what the school must supply.
List implementation milestones, training needs, support expectations and continuity questions. Separate commitments from assumptions so the school can resolve gaps before purchase.
05 / COMMERCIAL & RISK
Include terms, exclusions, privacy and exit questions in the same evaluation.
Ask for subscription and billing terms, tax basis, renewals, cancellation, included services, optional work and data access at exit. Compare responses on identical assumptions.
Document security and privacy questions for evidence-based review. Avoid treating a questionnaire answer as certification or legal advice; escalate material risks to the school’s qualified advisers.
06 / RESPONSE & ACCEPTANCE
Require evidence and define how the selected solution will be tested.
Ask vendors to answer each requirement with a status and evidence: shown in a live demonstration, available through configuration, handled manually, planned or not supported. Request a written explanation for material exclusions.
Define acceptance checks the school can perform before relying on the workflow. A strong requirements document remains useful through procurement, implementation and the first operational review.
A FIELD GUIDE FOR YOUR TEAM
A school ERP requirements outline
Use these sections to create a concise, testable document that different vendors can answer on the same basis.
| Lens | Question to ask | What to record |
|---|---|---|
| OUTCOMES & CONTEXT | Describe why the school is considering a new system. | A short context statement and ranked operational outcomes. |
| WORKFLOW REQUIREMENTS | Describe tasks, roles, exceptions and hand-offs in plain language. | A set of workflow scenarios and priority levels. |
| DATA, REPORTS & CONTROLS | Specify fields, access expectations and the decisions a report should support. | A data, permission and reporting requirement matrix. |
| DELIVERY & OPERATING CONDITIONS | Record migration, training, devices, connectivity and support assumptions. | A delivery plan with dependencies and responsibility boundaries. |
| COMMERCIAL & RISK | Include terms, exclusions, privacy and exit questions in the same evaluation. | A commercial comparison and risk-question register. |
| RESPONSE & ACCEPTANCE | Require evidence and define how the selected solution will be tested. | An evidence-based response matrix and acceptance criteria. |
CODEPEX IN CONTEXT
Useful guidance begins with clear scope.
For CodePex School ERP, the public capability registry is the owner-controlled source for released public claims. Product-specific scope and delivery must be confirmed against current evidence and a written proposal.
Product-specific statements are based on the current owner-controlled capability declaration. Ask CodePex to confirm any institution-specific configuration or unlisted requirement.