No, this isn’t going to be a confession.

Over the last few months it’s become apparent that our existing SIS didn’t really work for us, and not because it sometimes actually refused to work properly. Rather, the issue was one of fundamental design – and that’s nobody’s fault, probably, although I do wonder whether it’s something namelessSIS would have benefited from addressing.

Specifically, we use the SIS to enroll students on courses, but what about pre-registration for courses next year? These courses have limited seats so it’s important that we understand when they are full and plan ahead for the implications of this. It occurs to me that our SIS would be the logical place to do this, because it already knows all the students and courses, but there isn’t any way of representing this beyond the current year, as far as I can see, without maybe creating a fake year ahead of us in the system with all the potential problems that might ensue.

There is a wider related issue here – which is that sometimes the children signing up for next year’s courses will be prospective rather than current students. Working back from that, we can see that it’s not just a question of needing the ability to assign students to future classes, but we also need a waiting list.

In fact, my school – which currently sends out paper forms to parents who want to enroll their children – would like to do this electronically as far as possible anyway, so you see that these needs are really all part of the same required functionality. To that end, I concluded that nextSIS needed an ‘Admissions’ module, which has the ability to handle the application process as well as effectively creating a model of next year’s school in order to allow future class enrollments.

Tagged with:

2 Comments on “Admissions

  1. Hi,
    I think Admissions is at the heart of any SIS as that is where all your data starts, but it is also incredibly difficult(not impossible) to convert into something electronically.
    The reason is, for my school at least, there are so many human behaviours and actions that are tied to our application form, all the little jobs (essentially workflows)that various people do, from Account staff(checking for application fees), Admissions officers(sending interviews letters to applicants, creating a list of interviewees with data(age name, dob etc) for ESL testing staff and data about parents for parents interviews), ESL testing staff(who do the actual admissions test sand write up a report recommendation), principals, directors, office managers, they all have a little bit of input somewhere along the way.
    My point here is that all schools do something like this to varying degrees and the challenge to build something with this level of adaptability has never been done before.

    These ideas may however be too feature rich at this early this stage and I don’t want to drag you away from what really needs to be concentrated on but I think nextsis could use an admissions engine(like PowerSchool has for Scheduling)but it would collect data based on a certain admissions procedures needed for where the applicant was applying (e.g ECE, Primary, Secondary etc), unless you have 1 application form for everyone then this point is moot.

    I could go on for hours about this but I won’t, I look forward to seeing your progress, good luck.

    • Hello Rob,

      Thank you very much for your comments. I read once that the reason there isn’t a clear leader in the field of open source student information systems is that nobody can really agree on what such a system should be or how it should specifically work. You start off thinking that fundamentally schools work the same way, but actually the devil is in the detail of the business logic at each institution. Your comment about admissions procedures highlights this well.

      Since launching this project another school group has joined us in the effort so already it means that we are going to have to explore what unifies us and divides us and how we can create a system that provides sufficient flexibility in the context of those divisions so as to support our differing workflows where these exist.

      It occurs to me that the core problem is in defining the workflow in the first place when it comes to admissions, and to do this a project planning style metaphor is required where tasks are defined and an admissions procedure pathway is effectively created from this.

      So simplistically, for example, Letter A is generated leading to Form B being completed which then permits Check C and action D to take place simultaneously requiring the input or approval of persons E and F after which communication G can occur to the parents and so on. This way, we can at least model the process and create a transactional management interface for it.

      However, I’ll say up front that I don’t think this approach can be all things to all people and it’s actually easier to model as a paper exercise since we perhaps then accept that a lot is going on offline. For my school though, we’re aiming for a paperless admissions system where much more if not everything has to potentially be handled within the system.

      A wider question concerns whether – if an admission system is built with enough flexibility – if schools can gradually change their procedures to match it if the system doesn’t match it exactly.

      Thanks for the good luck wishes – we are going to need it!


Leave a Reply

Your email address will not be published. Required fields are marked *