Choosing a Student Information System
The Student Information System (SIS) serves as a school’s database of enrolled students, their attendance, class schedules, parents and emergency contacts, and often much, much more. The SIS is like a school’s brain – critical to its ongoing functioning – and so adopting or switching to a new one is no small decision. Although needs vary between schools, some basic considerations apply across the board. This post aims to familiarize you with some of the main questions to ask yourself (and prospective vendors) before making a decision.
Connectivity
Like any brain, the SIS is useless without a good nervous system connecting it to everything else.
Your meal tracking, phone/SMS alert, transportation management, and state reporting agency all need to share student contact information with the SIS. Ideally, the SIS should be able to reconcile any changes that come from those systems as well. For example, if a parent changes his or her phone number in one alert system, it should update seamlessly in all others.
Questions to ask:
Does your SIS support Single Sign-On?
Can your SIS export contact information to other systems?
Can your SIS import contact information from other systems?
Hosting
The brain also needs to reside in a top-notch head. Instead of relegating the SIS to an obsolete machine in a dusty closet, most modern SISs are hosted by the vendor. Generally, this is a good thing – hosting companies have experienced IT engineers available 24/7 to make sure that everything runs smoothly.The only catch is that a hosted SIS means you will pay an annual license instead of a one-time purchase price. Despite this, hosted instances are often cheaper than self-service options given economies of scale.
Questions to ask:
Is your SIS hosted, or do we need to host it?
Who provides the hosting, and what is their uptime?
If we need to recover from backup, how long does it take, and how far back can we go?
Extensibility
Have you heard the term “brain plasticity”? It refers to our brains’ helpful ability to change and form new connections throughout our lives. Your SIS should have plasticity, too.
No matter how good the out-of-the-box database structure, you will need to make additions to it. Reporting agencies ask for new information all the time, sometimes in unusual formats, and they often need you to retrieve that data at a moment’s notice. The database should support the addition of custom fields, and you should be able to specify, with each new addition, the type of data in the field, who has access to it, and whether students get a new value each year (e.g., learning goals) or not (e.g., allergies). Further, these fields should be easy to add to whatever area of the SIS makes the most sense for your school’s personnel.
Questions to ask:
Is it possible for school personnel to add custom fields and custom screens?
Can fields that change annually be stored alongside the student’s enrollment, rather than the student itself?
Can we create field sets that restrict the types of values for a given field?
(An example of this would be IEP fields, which typically come as pre-determined sets of accommodations.)
Scalability
Similarly to the ability to add custom fields, you’ll want your SIS to be able to add new capabilities (even if it’s doing everything you think you need at the moment). For example, assessment packages and discipline systems are common choices to add to a SIS. The SIS should be able to exchange data with other popular products easily, securely, and with minimal configuration.
Questions to ask:
What data can be exported to and imported from other systems?
(This is an extension of the questions asked in the Connectivity section, but many systems have different ways of handling contacts and, say, gradebooks.)Does your SIS have an API? If so, what data does it cover?
Does your SIS have ODBC access?
Security
Truthfully, security belongs at the top of the list. There’s plenty that you can do on your side to improve security, but as the old saying goes, the chain is only as strong as its weakest link.
At a minimum, any manner of PII (Personally Identifiable Information) should be encrypted, and all passwords should be “hashed” (i.e., scrambled in such a way that the correct password can be confirmed, but never extracted). Everything – everything – needs to be encrypted in transport since under FERPA you, as the LEA, are liable for any data leaked in transit.
Questions you should ask (preferably with your IT Specialist on the line):
How is PII protected? Which fields are encrypted? Are passwords hashed? (Bonus points if they can name the encryption algorithm!)
How is data transported, and how can designated people access the database?
(ODBC should be supported, but behind a firewall and require a VPN.)
Conclusion
With so many products out there and so many different considerations, choosing an SIS can feel overwhelming. We hope that this guide has given some basic structure to the decision-making process so that you can ultimately pick the SIS that best suits your school’s short- and long-term needs.
[This post contributed by Adam Labay, Senior SIS & Database Specialist]