Transitioning to a New Student Information System
Student Information Systems (SIS) are likely the most important database on campus. Even if they don’t do accounting, or fund-raising, they still handle the information and the work flow processes that are at the heart of the school– who are the families and the students, and what are their courses and schedules, and then reports, transcripts, attendance, and more.
We’ve been working on a transition to a new SIS for two years. Year one was researching all possible database solutions, including continuing to work with our current system. We reviewed 13 different options, and had full sales pitches from eight, and had a nice spreadsheet showing pros and cons of each. I can’t offer up that sheet online , since the numbers and costs and estimates were part of private conversations with the vendors, but at the end of the process we had a pretty good idea of where we needed to go.
We’ve had an in-house built FileMaker Pro 6 SIS for ten years. It was a great solution in many ways, because our in-house database developer could add wings off the system, and new reports, and new fields and functionality at will. The downside was that the system became so large that it became too difficult to upgrade on a consistent cycle. Secondly, FileMaker Pro 6 forced us to use interlinked database files (we reached about 200) that could only be opened in clusters, meaning that you could only open parts of the database at once, and we also had multiple user lists, meaning that people like myself were in the system multiple times (once as a parent, once as a staff member, etc.). In exports to Follett Destiny, for example, I have two accounts created.
In 2004, FileMaker Pro 7 was released, which enabled a unified database structure (not 200 interlinked files), but the problem was that all of the previous development work would have to be broken and rebuilt again to do the upgrade (about a year’s worth of work, with a new employee to cover regular database needs). However, there was a concern that even on FileMaker 7, 8, 9, 10, 11, we could have the same growth and renewal problems. Also, we would be building a full system based on only one school, and pretty much only one developer.
So, for six years, the school stayed on FileMaker 6, and each year we were concerned if Filemaker 6 would continued to run on the newer versions of OS X. In fact, we’re having problems on Snow Leopard at the moment with it…
To summarize, the school was used to a customized, easily changeable system. Those of you who have any of the big SIS systems from the main vendors probably know that "easily customized and changeable" isn't an easy road.
Our choice was Veracross
, because of its customization ability. The system can be customized school by school because of the way the do their the interface layers. Now, not all customizations are simply and fast, and new modules (such as the Transportation module we are having them build) are not free, but at least we have options going forward. Most importantly, it is a unified database with solid web interfaces for faculty, staff, parents and students that can be developed. Over time, we will fold in more modules that we need for counseling and other services into the unified system.
So, this year we started doing scripted exports of nearly all data out of FileMaker Pro 6, and documenting the data as best possible. These scripts are repeatable, so that when we do the real, final export at the end of this month, the same format with be retained but it will produce the latest data. Veracross has been working for several months on scripting theloading of the data into our Veracross system, and making changes as necessary to accommodate our data fields and structures we need. We are primarily moving to the logic used within the Veracross system (single user database, de-duplication routines), but they still need to know our special data management and analysis routines.
The main module we are having them build for us is Transport (which is integrated with our SIS for morning transport, attendance, after school daily sheets for students, athletic events management, one-off ride charges, taxis).
What will happen at the end of this month is that we will roll our database (sixth graders become seventh graders, etc.), export the final sets of data from the entire system, move our local system into read-only mode, and then Veracross will take our data for two weeks of scripted imports into Veracross (based on the scripts written over the past few months) and then de-duplicate and clean up our data (to achieve unification from the current disparate sources).
A great example of de-duplication is the problem of emergency contacts. In most system, emergency contacts in the SIS are “hanging records” about individuals who may have no other contact with the school. The bad part is that many or most emergency contacts are actually other parents, but the demographics entered for emergency contacts are never tied to the demographics in the parent records. Thus, phone numbers may change in one place, but not change in another. The Veracross system should de-duplicate the data (ether automatically or with human intervention), so that parents who appear as emergency contacts become “blue and underlined” and have their demographic data linked in both areas of the database, meaning a change to one automatically changes the other.
The other thing the Veracross system offers is ability for parents to directly update their demographic data online. The changes are directly processed into the system with no delay, but there is nightly polishing systems to clean up the data entry to school standards (ave. may be changed to Avenue). There are also change reports for the school to see all the online changes made, and roll-back the data if something is amiss. In fact, much or most of the entire system has an audit log, so that previous values can be seen and rolled back if needed. Our
current system doesn’t have that, and accidental changes means going to back ups to see what the data used to be.
However, the flexible reporting in FileMaker posed a problem for the transition. Users are used to centralized, heavily customized reports (like class photo lists, labels for school events, and customized and stylized reports for over 100 occasions). Veracross can do this for major reports (like transcripts, report cards, etc.) and generic reports of data, but not for dozens and dozens of uniquely customized and formatted reports, which often need minor adjustments all the time.
To side-step this issue, will will continue to use FileMaker 11 as a type of Crystal Reports for users. Using the API of Veracross, we will have a “mothership” FileMaker 11 database continually updating core data-sets to our server room for use for local databases. (Veracross is a hosted system running out of RackSpace data centers). Thus, FileMaker 11 will be on users desktops, with a single menu for a range of in-house built and customized reports. (Core reports will stay in Veracross.)
Using the local data store,we will also post-process data for other exports, such as to Moodle, Destiny, Catering and Security systems. Secondly, the local data store should give us enough information to be an emergency fall-back in case our cross-Atlantic connectivity to Veracross was interrupted for any significant length of time. Most of us could run on paper for a few days if needed, and the local data store could facilitate that.
Okay, that’s enough for now. Wish us luck– this is going to be a major change. As noted in our planning, we will lose some functionality and ways of doing things because of this transition, but the real value will be in the ways a unified system should help use enable better use and management of the data. Also, the system is designed to enable users to become more sophisticated in their use of information outside of the database, such as in the creation of Word merges that can be integrated back in the user interface. A web interface will be used by nearly all faculty, students and parents, but most staff users will use both the web interfaces and a light, local client.
Have a great summer.