Print and use first
Plan five evidence-led checkpoints from Day 0 to Day 30.
Treat these days as an adaptable planning rhythm, not a mandatory timetable. Shift a checkpoint when the school calendar, workflow risk or evidence requires it, and carry every unresolved exception with an owner and next decision date.
| Checkpoint | Owner | Deliverable |
|---|---|---|
| Day 0 · Start gate | School operating owner: __________ | Approved first workflow, roles, scope and exclusions: ____________________Day 0: review evidence and decision |
| Day 7 · Role-practice gate | Role-practice owner: __________ | Normal task, one likely exception and first-live-use instruction completedDay 7: review evidence and decision |
| Day 14 · Support-control gate | Support review owner: __________ | Classified support queue, corrected instruction and dated actionsDay 14: review evidence and decision |
| Day 21 · Routine-stability gate | Workflow reviewer: __________ | Repeatable routine and approved parallel-record or retirement planDay 21: review evidence and decision |
| Day 30 · Month-one gate | School decision owner: __________ | Signed month-one decision and the next bounded scope, if anyDay 30: review evidence and decision |
Keep the same checkpoint day in both parts.
Open part B: evidence, exit and decision| Checkpoint | Evidence | Exit criteria | Decision / open exceptions |
|---|---|---|---|
| Day 0 · Start gate | Configuration, source-data, role and support checks: ____________________ | School-approved start, constrained-start or hold criteria are met and recorded | Start / Constrain / Hold: ____ · Open exceptions and owner: __________Day 0: return to owner and deliverable |
| Day 7 · Role-practice gate | Observed practice, completed task and support-route evidence: __________ | Included roles can complete the task or safely route the exception without hidden help | Continue / Correct / Pause: ____ · Open exceptions and owner: ________Day 7: return to owner and deliverable |
| Day 14 · Support-control gate | Issue categories, aging, repeated questions, owners and due dates: ______ | Every material issue has a route, owner and next evidence date; unsafe workarounds are not required | Continue / Correct / Narrow: ____ · Open exceptions/owner: __________Day 14: return to owner and deliverable |
| Day 21 · Routine-stability gate | Completion, correction, access, data-quality and reconciliation evidence: ____ | The workflow is repeatable under the school rule and remaining risks are held, controlled or accepted by authority | Continue / Correct / Pause: ____ · Open exceptions/owner: ___________Day 21: return to owner and deliverable |
| Day 30 · Month-one gate | Acceptance results, support demand, open risks and source/role checks: ____ | The first promise has accepted evidence and any expansion has its own owner, preparation and gate | Continue / Correct / Pause / Expand: ____ · Carry-forward/owner: ____Day 30: return to owner and deliverable |
Keep the same checkpoint day in both parts.
Return to part A: owner and deliverableDays −7 to 0
Choose a small first promise the school can actually verify.
The first release needs a clear job. ‘Use the ERP’ is not a job; ‘complete and review every assigned class attendance register by the agreed time’ is.
Start with one or two frequent workflows that have an identifiable owner, a prepared source record and a visible completion state. Attendance, a selected communication routine or a controlled fee-record task may be suitable, but only when the school has agreed the operating rule and the product configuration has been validated.
Outcome
Name the completed task.
Describe what a role will finish, by when, and what the reviewer will see when it is complete.
Owner
Assign the operating decision.
Name who defines the rule, who performs the task, who checks it and who resolves exceptions.
Evidence
Agree the acceptance signal.
Use observable evidence such as completed assigned records, reconciled totals or successful role-specific task checks.
Boundary
Write down what is not launching.
Keep later modules, reports and integrations outside the first promise until their data and owners are ready.
Practise the role
Train around the task, not around a tour of every screen.
People remember the route that helps them finish today’s work. Give each role a short scenario, a clear end state and a way to recover from the common exception.
Show the school rule first.
Explain the responsibility, deadline and escalation path before demonstrating where the controls appear.
Demonstrate one complete example.
Use representative, non-sensitive training data and show the normal path from start to confirmation.
Let the participant repeat it.
The learner completes the same task while the facilitator observes where labels, data or permissions cause hesitation.
Practise one exception.
Include a missing record, wrong context, correction request or access problem and show the approved support route.
Confirm the next live task.
End with the exact date, responsibility and support contact for the first real use.
| Role | Practice task | Evidence to observe |
|---|---|---|
| Teacher or task owner | Complete one assigned routine and recognise the confirmation state | Can finish without a facilitator taking control |
| Reviewer or administrator | Find incomplete work, verify an exception and record the next action | Can distinguish missing, complete and disputed records |
| School support contact | Resolve one access or configuration question through the agreed route | Can identify whether the issue is policy, data, access or product support |
| School leader | Review the acceptance evidence without asking for unrestricted access | Can decide whether to continue, correct or pause the rollout |
Support live use
Turn early questions into a visible improvement queue.
Silence does not prove adoption. Staff may be using a workaround, repeating a task outside the system or avoiding an unclear exception. Make support easy to reach and classify what arrives.
- Hold a short daily check during the first live week, then reduce the frequency when the routine stabilises.
- Separate policy questions, source-data errors, permission issues, usability questions and confirmed product defects.
- Record the affected role and workflow without copying student, credential, payment or confidential school data into an informal support channel.
- Publish corrected instructions once, instead of asking every staff member to discover the same workaround.
- Keep an owner and target date beside each unresolved item.
Review before expanding
Use a written month-one decision: continue, correct, pause or expand.
The first-month review should compare the agreed promise with observable evidence. Expansion is a decision, not an automatic calendar event.
| Question | Evidence to inspect | Possible decision |
|---|---|---|
| Is the first workflow complete? | Assigned tasks, missing records, corrections and reviewer sign-off | Continue or correct the operating rule |
| Can each role work independently? | Observed task practice and repeated support categories | Refresh role training or simplify the path |
| Is the source data trustworthy? | Reconciliation results, duplicate or unmapped records and open exceptions | Correct data before adding another module |
| Are access boundaries working? | Role tests, account changes and inappropriate or missing access reports | Correct permissions and repeat validation |
| Is parallel work reducing safely? | Approved retirement plan for duplicate sheets, registers or exports | Retire only after the replacement record is accepted |
Expand when
- the first workflow meets its written acceptance evidence
- staff know the support and correction route
- source data and permissions have been reconciled
Correct when
- one role or exception still depends on informal help
- the configured rule differs from school policy
- parallel records disagree without an owner
Pause when
- access exposes the wrong school or learner context
- a required record cannot be reconciled
- staff are asked to bypass a documented approval or safety control
Frequently asked questions
Clarify the decision and its boundaries.
Use these answers as a starting point, then verify the relevant source, rule and school process.
Should a school launch every ERP module at the same time?
Not by default. A phased rollout usually makes ownership, data quality, role training and acceptance evidence easier to verify. A school may choose a broader launch when dependencies require it, but the scope and go/no-go evidence should still be explicit.
Is staff login activity enough to measure adoption?
No. Login activity does not show that a school task was completed correctly. Review task completion, unresolved exceptions, corrections, support demand and whether duplicate work is reducing safely.
Who should own school-software adoption?
The school should name an operating owner with authority over the workflow, supported by role leads, data or access owners and the vendor’s agreed implementation contact. Adoption should not be left to one enthusiastic user without decision authority.
When can the school stop using the old register or spreadsheet?
Only after the replacement record has been reconciled, accepted by the responsible school owner and covered by a written retention, export or retirement decision. Do not delete the only trusted source merely because a new screen is live.
Primary sources and further reading
Read the official material behind the context.
Sources were reviewed when this explainer was updated on 2 September 2026. Always verify the current official version before relying on a rule or requirement.
Ministry of Education
National Digital Education Architecture (NDEAR) main reportPrimary architecture context for interoperable, evolvable digital education systems and ecosystem responsibilities.
Ministry of Education
National Initiative for School Heads’ and Teachers’ Holistic Advancement (NISHTHA)Official programme context for structured teacher and school-leader capacity building.
NCERT · Ministry of Education
About DIKSHAOfficial context for India’s national school-education platform and professional-learning ecosystem.