Product guides
What an IT lead should document about school management, ERP, and SIS
What an IT lead should document about school management software: systems, data flows, roles, integrations, incidents, recovery, support, and change.
Document the operating boundary
An IT lead should be able to explain which system is authoritative, what data moves, which roles access it, what the school owns, what the supplier owns, and what happens when the normal path fails. A diagram without ownership is not an operating document.
Start with the first workflow and record its source, destination, fields, timing, validation, approval, notification, support, retention, and recovery.
Keep four records current
Maintain a data-flow map, role and permission matrix, integration inventory, and incident or recovery runbook. Link each to an owner and review date.
- Systems, suppliers, and subprocessors
- Data fields, purposes, copies, and retention
- User, family, support, and privileged access
- Backup, restore, outage, and reconciliation steps
- Change, release, and rollback decisions
Write for operators
GOV.UK procurement guidance recommends attention to data protection by design, minimum necessary data, access control, security, subprocessors, incident notification, and data return or deletion. The U.S. Department of Education data governance checklist adds quality, lifecycle, sharing, disposal, and monitoring.
Use plain language beside technical details. During an incident or term start, staff need to know who acts, what is safe to do, what must be escalated, and how temporary work is reconciled.
Review documentation against reality
At 30, 60, and 90 days, compare documents with observed workflows, support questions, access reviews, exports, and recovery tests. Update the record when a role, vendor, field, integration, calendar, or policy changes.
Make the next step specific
Use this guidance to improve one bounded part of what an IT lead should document about school management software. Name the person who owns the decision, the record or workflow affected, the evidence needed, and the date for review. Keep the test small enough for operators to complete and specific enough for a later audit. Record the result, the next action, and the condition that would make the team revisit the decision.
