Choosing Software When You Run Both a School and a College

If you run a school with a +2 wing, or a campus that also runs school classes below it, you have almost certainly noticed something odd about the software market in Nepal. Every vendor says they serve schools and colleges. Their homepages say it, their brochures say it, their sales calls say it. And yet the moment you sit down with the product, one of the two halves of your institution turns out to be an afterthought.

This is not usually dishonesty. It is what happens when a product was built for one shape of institution and then sold to another. The claim is made at the level of a sentence; the difference shows up at the level of a database. This guide is about how to tell them apart before you commit, and the questions are useful whichever vendor you end up choosing, including if that is not us.

Why a school and a college are not the same system

A school and a college are not two sizes of the same thing. They keep time differently, they measure differently, and they answer to different people. Almost every hard problem in a hybrid institution comes from one of those three.

They keep time differently

A school runs an academic year. A student joins Grade 8 in Baisakh and is in Grade 8 until the year ends. A campus runs semesters, and a student can be in the third semester while still carrying a subject from the first. If the software holds one enrolment per student per year, and most school software does, the campus half of your institution is being described by a model that cannot represent it. You will find this out not in the demo but in the second semester, when someone asks where the back paper goes.

They measure differently

A school subject has a mark. A campus subject often has two, an internal component and an external one, in a split the affiliation sets, commonly 40 and 60. It also has credit hours, which is how a semester result becomes a GPA and how several semesters become a CGPA. A product that holds one number per subject can be made to store a college's marks, in the sense that a spreadsheet can store anything. What it cannot do is compute the figure that goes on a transcript, which means someone in your office is still doing that by hand.

They answer to different people

Your school wing and your +2 wing report into the government education system, which is where the IEMIS return comes from. Your bachelor's programmes report to a university, in that university's shape and on its calendar. One institution, two reporting obligations, neither of which cares that the other exists. If you are working out the school-side half of that, we have a separate guide to IEMIS reporting.

The seven questions that expose the difference

Take these into a demo. They are deliberately specific, because a general question about whether a product supports colleges will always be answered yes. Ask the vendor to show you, in the product, rather than to confirm it.

1. 1Show me a student enrolled in two sessions at once. This is the single most revealing question. If a learner cannot be in more than one place at a time in the data model, everything else about the campus wing is a workaround.
2. 2Show me a subject with an internal and an external mark, and show me where the split is configured. Not two subjects that happen to be named 'Maths internal' and 'Maths external'.
3. 3Show me a credit hour, and show me the CGPA it produces across three semesters. If the answer involves exporting to Excel, the answer is no.
4. 4Show me a back paper. Specifically, show me a second attempt at a subject that does not erase the first attempt, because the first attempt is part of the record.
5. 5Show me one fee ledger covering both wings. Two products, or two accounts in the same product, means reconciling twice and never being sure of a total.
6. 6Show me one staff list where a lecturer who also teaches Grade 10 appears once. Anyone teaching across both wings is the test of whether this is one system or two systems sharing a login page.
7. 7Show me what a parent sees, and what an adult student sees. Your school wing has guardians. A good part of your campus wing does not, and a product that assumes a guardian on every record will make your bachelor's students into somebody's children.

The two-system trap, and why it is tempting

Faced with all of this, plenty of hybrid institutions do the obvious thing and run two products, one for the school and one for the campus. It solves the fit problem immediately, and it creates a slower problem that is harder to reverse.

• Your total fee position is now an addition sum between two systems, done by a person, at a point in time. It is never quite current and never quite trusted.
• A teacher who works across both wings exists twice, with two records, two leave balances and two payroll rows.
• A student who moves up from Grade 12 into your own bachelor's programme is entered again from scratch, and their history stays behind in the other system.
• Two subscriptions, two vendors, two support relationships, and two answers whenever something disagrees.
• Two copies of children's personal data, in two places, secured to two different standards.

None of these is dramatic on the day you set it up. They compound. The point at which most institutions notice is the point at which unpicking it is a year's work.

Two systems do not split the work in half. They add a third job, which is keeping the two of them agreeing with each other.

What to insist on, whoever you buy from

If you take nothing else from this, take these four. They are not features so much as properties, and they are hard to retrofit.

1. 1One record per person. A student, a teacher or a guardian appears once in your institution, whatever wing they are attached to, and their history follows them when they move between wings.
2. 2One ledger. Every rupee charged and collected across both wings lands in one place, so a total is something you read rather than something you assemble.
3. 3Permissions that follow the wing. Your campus registrar should not automatically be able to see Grade 4's records, and your school's class teachers should not see campus results. This is a server-side question, not a menu-visibility question, and it is worth asking exactly how it is enforced.
4. 4An export you could actually leave with. Ask what happens to your data if you cancel, how long you have to take a copy, and in what format. A vendor who answers this comfortably is telling you something about the rest of the relationship.

Where NepEdu stands against these questions

It would be strange to publish a checklist and then dodge our own questions, so here is how NepEdu answers each of them.

Both wings run in one system: one record per student and per staff member, one fee ledger with receipts, concessions, refunds and reversals that keep their reasons, attendance and leave, staff records and Nepal payroll, exams and published results, the library, bulk import from Excel with a dry run first, and permissions enforced on the server rather than in the interface. IEMIS reporting for the school and +2 side runs from the same records. Questions five and six are a yes: one ledger, and one staff list, across both wings.

The campus side is answered in the same records rather than by relabelling the school one: semesters run as sessions in their own right, a student can be enrolled in more than one at once, credit hours carry through to a CGPA computed across semesters, a subject holds its internal and external components separately, a back paper is its own attempt rather than an edit over the first, and registration numbers sit on the student record with the admit cards, mark ledgers and transcripts generated from them. Question one, the one we called the most revealing, is a yes.

Which is the point of writing the checklist in the first place. A hybrid institution should not have to choose which wing gets the good software, and it should not have to run two systems to avoid choosing.