Core worksheet
Assign one owner, one verifier and one acceptance record per workstream.
Use names or accountable roles rather than a department alone. Evidence should be inspectable: a signed reconciliation, configured scenario result, approved message or support roster—not “discussed” or “looks fine.”| Workstream and owner | Acceptance evidence and verifier | State and due date |
|---|---|---|
| Scope & success · Owner: __________ | Signed workflow list, exclusions, acceptance questions · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| School configuration · Owner: __________ | Academic year, classes, sections, subjects, fee/exam/attendance rules and sample scenarios · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Student & relationship data · Owner: __________ | Source counts, field rules, relationship checks, duplicates and exception register · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Role access · Owner: __________ | Representative Administrator, Teacher, Parent and Student least-access tests · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Priority workflows · Owner: __________ | Normal path, exception and evidence completed for each launch workflow · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Staff readiness · Owner: __________ | Task-led practice, exception recovery and named support route · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Parent/student preparation · Owner: __________ | Approved message, relationship checks, access alternatives and support path · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Payment or third party · Owner: __________ | Written configured scope, test result, charges/dependencies and reconciliation owner · Verifier: __________ | State: Ready / N.A. / Hold · Due: __________ |
| Security & privacy · Owner: __________ | Approved access, minimum-data handling, incident and escalation routes · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Fallback & continuity · Owner: __________ | Trigger, alternate method, record merge/reconciliation and authority tested · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
| Early-life support · Owner: __________ | Hours, triage, school first line, product escalation and daily review roster · Verifier: __________ | State: Ready / Conditional / Hold · Due: __________ |
- Every launch workstream has exactly one accountable owner even when several people contribute.
- A different authorised person can inspect or verify each critical acceptance record.
- Conditional items state the limitation, compensating control, owner and expiry date.
- Not applicable is explained; it is not used as a shortcut for untested work.
- The matrix points to restricted evidence rather than copying personal records into the meeting pack.
Decision frame
Name who can launch, hold, limit and reverse the decision.
A responsibility matrix fails when everyone contributes but no one has authority. Separate the school’s operational decision, implementation evidence, technical advice and product support responsibilities.| Field | Record for this launch | Required clarity |
|---|---|---|
| School and launch scope | School/campus: __________ · Workflows: __________________ | Only the named scope is being considered |
| Planned activation window | Date/time/time zone: ___________________________________ | Cut-off, validation and family/staff timing are distinct |
| School launch authority | Name/role: _____________________________________________ | Can approve launch, constrained launch, hold or fallback |
| Implementation lead | School: __________ · Schylva: __________ | Coordinates evidence but does not replace school authority |
| Data acceptance authority | Name/role: _____________________________________________ | Can confirm migration reconciliation and open exceptions |
| Operational fallback authority | Name/role: _____________________________________________ | Can invoke the approved alternate process |
| Matrix version | Version/date: __________________________________________ | All reviewers use the same evidence pack |
Governance context
Review and approval roles should remain visible.
The NDEAR main report describes governance with strategic direction, review, approval, programme implementation, technology and data-protection expertise. A school launch is much smaller, but the same distinction between direction, execution and review helps prevent implied approval. This worksheet is not an NDEAR requirement or certification.
Decision boundary
A vendor cannot accept the school’s operational risk for it.
Schylva can provide product, configuration, migration and support evidence within the written scope. The school remains responsible for its calendar, policy, source records, authorised users, communications, operational acceptance and decision to activate or continue an alternate process.
Evidence before confidence
Test the launch in role context and reconcile the result.
A page opening successfully is only one observation. Acceptance should connect the configured school rule, authorised role, representative record, resulting state and owner who can correct an exception.| Layer | Representative acceptance question | Evidence to retain |
|---|---|---|
| Configuration | Does the configured structure match the approved school scope? | Versioned configuration checklist and authorised sign-off |
| Migration | Do totals, samples, identities, relationships and exceptions reconcile? | Source and target counts, samples, exception register and acceptance authority |
| Access | Can each representative role do only its intended work? | Least-access scenario results; no shared credentials |
| Workflow | Can the normal path and likely exception reach the expected state? | Scenario, inputs, expected result, observed result and open issue |
| Communication | Can the intended audience recognise and safely use the official route? | Approved message, channel plan, rehearsal and alternative route |
| Support | Can a school user classify and route an issue without exposing secrets? | Triage guide, contacts, hours, escalation and sample ticket |
Implementation evidence
Trials, verification and training answer different questions.
The Ministry of Education’s Shaala Darpan initiative summary reports record verification, trial runs, migration activity and training in a government programme. It does not prescribe this matrix or prove that the same sequence fits a private-school ERP launch; it illustrates why a single technical milestone is not the whole readiness case.
Evidence boundary
Do not copy production data into a general readiness pack.
Record totals, redacted examples, issue references and controlled evidence locations. Keep personal records, credentials, payment material, safeguarding context and security detail inside the school’s authorised process with access limited to the decision purpose.
Before the cutover
Write the stop conditions and fallback before pressure begins.
A fallback is an approved operational method, not automatically a software rollback. It must say what stops, how new records are captured, which source remains authoritative and how parallel entries will later be reconciled.| Condition | Authority and immediate action | Recovery evidence |
|---|---|---|
| Material identity or family-link mismatch | Hold affected role/workflow · Authority: __________ | Corrected relationship, access retest and authorised approval |
| Critical source-to-target reconciliation gap | Hold migrated workflow · Preserve source · Authority: __________ | Root cause, corrected trial, repeat reconciliation and exception decision |
| Role can view or change unauthorised context | Disable or hold affected access · Escalate immediately | Permission correction, least-access retest and incident handling record |
| Priority workflow unavailable | Invoke approved manual/previous route: __________ | Time-bounded fallback log and safe later reconciliation method |
| Support route not staffed or understood | Delay required use or narrow scope · Authority: __________ | Published roster, rehearsal and escalation confirmation |
| Family/staff preparation materially incomplete | Continue parallel/optional period or delay requirement | Barrier closure, representative rehearsal and new review date |
Rollback distinction
Do not promise a one-click technical rollback unless it is designed and tested.
A school may pause a workflow, return temporarily to a prior process or restrict scope without reversing every technical change. Define the record owner, recovery point, data captured during fallback, duplicate risk, reconciliation method and decision authority in writing.
Continuity context
Contingency plans need testing, training and maintenance.
NIST SP 800-34 Rev. 1 is US federal information-system guidance, not an Indian school mandate. Its emphasis on recovery priorities, alternate methods, plan testing, training and maintenance is useful background when the school designs its own proportionate operational fallback.
From project to operation
Turn implementation knowledge into an early-life support handoff.
The person who knows why a field, role or workflow was configured should not disappear at activation. Carry decisions, known limitations and unresolved evidence into the support rhythm.| Handoff item | Receiving owner | Evidence and review |
|---|---|---|
| Approved scope and exclusions | School first-line owner: __________ | Versioned scope link · Review: __________ |
| Known conditions and workarounds | Operational owner: __________ | Expiry, risk, safe instruction and permanent fix owner |
| Migration exception register | School data owner: __________ | Restricted location, priority, correction and acceptance status |
| Access and relationship exceptions | Authorised account/data owner: __________ | Minimum issue reference and restricted verification route |
| Product issue escalation | Enrolled-school Schylva contact: __________ | Issue severity, reproducible context and dependency owner |
| Daily launch review | Meeting owner: __________ | Time: ______ · Metrics: completion, exceptions, support and data quality |
| End of early-life support | School launch authority: __________ | Exit criteria, open actions and steady-state owners |
School policy
Stay with the school owner.
Product support should not invent attendance, fee, assessment, communication or records decisions.Data and access
Use the authorised school route.
Identity, relationship, corrections and permissions require restricted verification and named responsibility.Product issue
Escalate through the enrolled-school route.
Provide the minimum reproducible role, context, time and expected versus observed state.Third-party dependency
Keep the dependency visible.
Name provider state, school action and product action instead of promising a fixed resolution outside control.Go / constrained go / hold
End the review with one signed decision and dated conditions.
Do not average several critical failures into an overall green status. Resolve every hold criterion, or explicitly narrow the launch so the affected workflow, role or data population remains outside required use.| Decision field | Record | Accountability |
|---|---|---|
| Decision | Go / Constrained go / Hold: ____________________________ | School launch authority: __________ · Date/time: __________ |
| Activated scope | Workflows, roles, campuses and dates: ____________________ | Everything else remains outside required use |
| Accepted conditions | Condition, control, owner, due date, expiry: ______________ | No condition without a named authority and review date |
| Fallback state | Trigger, method and reconciliation owner: _________________ | Fallback is available to affected users |
| First review | Date/time and evidence pack: _____________________________ | Completion, exceptions, support, access and data quality |
| Next expansion gate | Evidence required before adding scope: ___________________ | No automatic expansion because the date passed |
Source retention
Do not delete source records because activation succeeded.
Retention, archive, disposal, export and transition responsibilities must follow the school’s approved records, contractual, security and legal process. Keep any necessary reconciliation and fallback evidence until authorised owners decide otherwise. This worksheet does not set a retention period.
Product and data boundary
Use the matrix to expose assumptions—not to invent Schylva capabilities.
The matrix spans school responsibilities, external dependencies and current product scope. Each row should name which party owns the evidence and which detail must be confirmed in writing.Standard Schylva launch services
- Standard onboarding
- Initial school configuration
- Initial data migration
- Staff training
- Ongoing product support
Confirm in the school plan
- Agreed launch scope, owners and timing
- Source records, field rules, migration and reconciliation
- Configuration priorities and role acceptance
- Training arrangement and school communication
- Fallback, activation gate and enrolled-school support route
Do not assume
- A universal launch date, sequence or readiness score
- One-click migration, rollback or automatic source deletion
- Every third-party integration or historical record is included
- A passing login test proves data, role and workflow acceptance
- This matrix provides legal, security or board compliance
Data architecture context
Portability, access control and audit evidence belong in the design discussion.
The NDEAR Open Standards and Specifications discusses interoperability, portability, consent, access control, security and audit trail as education-system concerns. This worksheet uses those themes as questions; it does not claim Schylva certification or complete conformity with NDEAR.
Privacy boundary
A signed launch matrix is not a privacy assessment.
Review the Digital Personal Data Protection Act, 2023, Rules, 2025 and later commencement material with qualified advice. Define applicable purposes, notices, access, correction, retention, security and child-data responsibilities separately from the operational go-live meeting.
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.What is a school ERP launch-readiness responsibility matrix?
It is a versioned record of launch conditions, accountable owners, verifiers, acceptance evidence, current status, hold criteria, fallback decisions and support handoffs. It supports a decision; it does not replace testing, the implementation plan or school authority.
Who should make the final go-live decision?
The school should name an authorised leader who can approve, constrain, hold or reverse the operational decision. Implementation and product teams provide evidence and advice within scope but do not accept the school’s policy and operational risk on its behalf.
Can a launch proceed with open issues?
Only through an explicit school decision. Each accepted condition should state the affected scope, risk, compensating control, owner, due date, expiry and next review. Any issue meeting a written hold criterion should be resolved or excluded from required use.
What counts as migration acceptance evidence?
Use source and target totals, field and relationship checks, representative samples, duplicate and exception registers, calculation or balance reconciliation where relevant, and an authorised data owner’s decision. A matching row count or successful file upload is not sufficient alone.
Is fallback the same as technical rollback?
No. Fallback may mean a time-bounded manual or prior operational method for an affected workflow. A technical rollback reverses system changes and should never be promised without design and testing. Both need authority, record ownership and reconciliation planning.
Should the school delete old records after launch?
Not merely because activation succeeded. Retention, archive, disposal and transition should follow the school’s approved contractual, legal, security and records-management process, with reconciliation and fallback needs considered.
What launch services does Schylva include?
The standard launch service includes onboarding, initial school configuration, initial data migration, staff training and ongoing product support. The written school plan confirms scope, sources, validation, timing, responsibilities, support and any dependency or excluded work.
Does completing this matrix guarantee a successful or compliant launch?
No. It makes responsibilities and evidence visible but cannot guarantee outcomes or establish legal, security, privacy, board or contractual compliance. Verify current requirements and obtain specialist advice where needed.
Primary sources and further reading
Read the official material behind the context.
Sources were reviewed when this checklist was updated on 2 September 2026. Always verify the current official version before relying on a rule or requirement.National Digital Education Architecture
NDEAR Main Report Official governance, implementation, data-protection and ecosystem context. It does not prescribe this school-level responsibility matrix.National Digital Education Architecture
Open Standards and Specifications for NDEAR Official education standards context for interoperability, portability, consent, privacy, access control, security and audit trails. No conformity claim is made.Ministry of Education, Government of India
Major ICT Initiatives — Shaala Darpan Official historical programme summary referencing record verification, testing, trial runs, migration and training; used as implementation context only.National Institute of Standards and Technology
SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems US federal guidance used only for general contingency-planning concepts such as recovery priorities, alternate methods, testing, training and maintenance.Ministry of Electronics and Information Technology
Digital Personal Data Protection Act, 2023 Primary statutory source for qualified review. This worksheet does not determine applicability or provide legal advice.Ministry of Electronics and Information Technology
Digital Personal Data Protection Rules, 2025 Official Gazette notification with phased commencement. Verify later notifications and obtain qualified advice where required.