Operating model for school management, ERP, and SIS

Software needs an operating model

A platform does not decide who owns a student definition, approves a correction, answers a family question, reviews staff access, or chooses the next implementation phase. Those are operating decisions. If they remain implicit, the school may have a configured system without a dependable way to run it.

The model should fit the school’s size and structure. A small school may combine roles; a group or multi-campus organization may need central standards with local owners. The principles remain the same: clear authority, visible evidence, and safe escalation.

Define six ownership areas

Name a primary owner and backup for each area, with a decision path when teams disagree.

• Product and workflow ownership: what the school is trying to accomplish.
• Data ownership: definitions, quality, correction, retention, and exports.
• Access ownership: roles, reviews, exceptions, and leavers.
• Academic-calendar ownership: dates, working days, periods, and publishing windows.
• Support ownership: questions, incidents, training, and escalation.
• Change ownership: requirements, prioritization, testing, and release decisions.

Create decision rights

Document who recommends, who approves, who must be consulted, and who is informed for common decisions. Include a new field, a changed permission, a new integration, a data correction, a report definition, and a phase expansion.

Do not confuse consultation with approval. A team may explain the operational effect without owning the final decision. The record should make that distinction visible.

Run a data-quality rhythm

Use a regular review for duplicates, missing values, stale contacts, reconciliation exceptions, report definitions, and unresolved ownership. The frequency should reflect risk and school workload. Record the issue, owner, correction, validation, and date.

The U.S. Department of Education’s data-quality guidance connects reliable decisions to business rules, validation, infrastructure, and professional learning. Include training when a recurring data error is caused by unclear practice rather than a technical defect.

Run an access and change rhythm

Review staff roles after role changes, leavers, term transitions, campus moves, and new workflows. Test a few high-risk scenarios rather than assuming a role list remains correct forever.

Use change control for requirements and configuration. Every change should state the reason, affected workflow, risk, test, owner, effective date, and rollback or hold decision.

Define support and escalation

Classify questions as training, data, configuration, integration, product boundary, privacy, security, or incident. Give each category an owner and response route. A support queue without classification hides recurring problems and makes staffing difficult.

During term-start or other high-risk periods, use a short daily review of unresolved issues. Close the loop with the affected staff or family rather than only updating an internal ticket.

Measure and improve the model

Review adoption, corrections, support questions, access exceptions, workflow completion, and the outcomes defined in the original brief. Expand only when ownership and evidence are strong enough to support additional complexity.

An operating model is working when people know who decides, where evidence lives, what happens when a process fails, and how a change becomes safe for the next team or family.

Use the review to remove unnecessary process as well as add control. If an approval exists only because ownership was unclear, clarify the owner and test whether the extra step can be retired safely. Governance should make work dependable, not make every action slower.

Keep a short quarterly review record with decisions, unresolved risks, evidence age, and next actions. This makes the model resilient when staff or vendors change and gives leadership a concrete basis for deciding whether to expand, hold, or consolidate work.

Share the review with the owners who must act on its decisions.