Student information systems, revisited

It was a dark and stormy night and I was reviewing a recent dump of transcript data from our student information system.  The more comma-separated values I read, the more my heart was gripped with icy fingers of dread.  Duplicated records, failed imports, incorrect credit and grade calculations…It was a grisly scene.

I've talked about student information systems before [Scheduling (enough said) and So about those student information systems...], but, as the horror builds with my own SIS implementation, I thought it was about time to revisit the subject.  It is almost Halloween, after all.

The problems with our particular implementation, like those of many schools and higher education institutions, are manifold.  Sure, the problems began when some very non-technical people (who thankfully are no longer with the district) decided to jump on the web-based SIS bandwagon.  These same people jumped at a system without defining user requirements, conducting prototyping and testing, or otherwise taking any of the other steps that most reasonable IT folks would consider essential steps of the systems development lifecycle.

Even better, the system they chose was incredibly immature, lacking many basic features and filled with a variety of vaporware that was supposed to appear in "future releases".  While many of these features did eventually appear, the system remains hard to use, hard to administer, and incredibly resource-intensive, both from a hardware/networking standpoint, and from a financial perspective.  In fact, the only requirement that it actually satisfies is that it produces NCLB-style reports fairly easily for administrative staff.  

I've also made it pretty clear before that I don't see a place for early adoption of new technologies in most areas of Ed Tech.  As a case-in-point, because we adopted this product so early in its development, a number of bugs, screw-ups, and workarounds were built into our implementation.  Our vendor was so severely lacking in understanding of the final product (as were many vendors for this SIS), that the consequences of said bugs, screw-ups, and workarounds are only now becoming apparent as the SIS matures.  We've taken to calculating GPAs and class ranks in an external database that a consultant built for us since we don't trust the transcripts that our SIS produces (it's not just paranoia, either; the data dump that I described above, though a bit dramatically, does, in fact, show a variety of corruptions and errors).

I'm hoping that this story has a happy ending, though.  I was talking with another vendor of student information systems the other day.  He actually asked some questions about end user requirements.  He also told me that their system wasn't web-based and alluded to the same backlash against slow, buggy systems deployed from a web server.  The system that he sells is client-server based; they deal with remote access through Windows Terminal Services, allowing a much richer, faster environment, unconstrained by browsers, cookies, sessions, etc.  Better yet, when I asked him about NCLB reporting requirements, he said, "Oh yeah, we have a module that takes care of that stuff, but we really focus on the day-to-day uses of our system."  Hmmm…Where was he 4 years ago when the horror began? 

Like the bad teenage actors who plunge onward in our favorite horror movies, despite the knowledge that they will soon be hacked to pieces, I will make my way deeper into the world of student information systems and let you know how it goes if we make a switch.  Or if I just get cut into a lot of pieces by a chainsaw-wielding madman and we just stick with our current system.