BCeSIS is going, but not soon

This article will appear in the November issue of TEACHER, the newsmagazine of the BCTF.

 

The good news is that BCeSIS will be replaced.  The bad news is that it won't be soon, and getting it right the next time will not be easy.

BCeSIS is the troubled student information system that the Ministry has spent $100 million on in the last decade.  That doesn't count the many local costs and the price of extreme aggravation of many teachers produced by the limitations of BCeSIS.

The Ministry knew by the fall of 2010 that BCeSIS had to be replaced. There had been a disastrous opening of school where the system simply failed to deliver at a crucial time in the school year. In addition, the Pearson corporation bought out the company that developed the software for BCeSIS, the AAL company.

Pearson is expanding its reach into all aspects of education by buying companies and closing down their products. In effect, they are buying a customer base for their existing products. This is what Pearson did--it told the ministry that the company would stop supporting BCeSIS software as of 2013 and offered its PowerSchool student information system to replace it.

Pearson's offer was not accepted and the Ministry started a process of finding another alternative.  The process has included getting advice from consultants and defining design requirements.

The Ministry last summer brought together a group of 44 administrators, teachers and others to define the "Functional Requirements."  Those involved were recommended to the Ministry by superintendents. The functional requirements are a key to whether the new system will be better or worse for educational practice.

Ursula Franklin tells us that "every tool shapes the task."  The student information system shapes what goes on in our schools and a different one will shape it differently.  That is why it must be consistent with what we philosophically believe is appropriate for a sound public education.

The tool shapes the task--so the design of the tool is crucial.  The "functional requirements" are that chance to influence the design of the tool.

The document that the Ministry has produced has 48 pages of what will be told to the businesses that want the contract for the next student information system.  The functional requirements are up on the Ministry website at www.bcedplan.ca/actions/technology.php. 

Not surprisingly, a significant share of the requirements identified are aimed at not repeating the problems we all had with BCeSIS.  It must have a user interface that is friendly and easy to use.  It has to be flexible and eliminate what Assistant Deputy Minister Renate Butterfield calls the "pain points," the many elements that took too much time, were inflexible and didn't do what they should.

However, designing the future primarily based on correcting the failures of BCeSIS in the past is what Marshall McLuhan called driving forward while you are looking in the rear-view mirror.  The BC Education Plan is supposed to lead to some changes in practice in our schools.  What kind of a student information system will serve the needs of a system that is different from the one that existed when BCeSIS was designed?

But designing for the future is difficult when the BC Education Plan is a work in progress, is centred on "personalization," and which has no common definition.  The "functional requirements" document addresses that by calling for flexibility in many of the areas, presumably allowing the software to be shaped to fit the evolving definition of BC's education system.

The next stage of the Ministry process is to issue a request for proposals.  This invites companies to respond with a proposal for a system that would meet the needs defined by the "functional requirements."

Is any company likely to meet all those requirements?  They certainly were not when BCeSIS was developed.  The Ministry says that the technology consultants they hired to survey what is out there said that there are off-the-shelf systems that have been developed for a number of states in recent years.  The US government has thrown hundreds of millions to have states develop centralized data systems.  Unfortunately, that is because the No Child Left Behind and the Obama education policies require states to focus on identifying "failing schools" and creating systems aimed at merit pay and firing teachers based on student standardized test scores.  They are not directed at supporting progressive pedagogy in a high-performing school system.

The Ministry doesn't want to buy software or hardware or run the implementation and training necessary for a new system.  Rather, they want to buy a service for a 10-year period from a company, much as many employers buy a payroll service, for example.  Only a large corporation that is already running a similar service is likely to be able to provide this.  And, of course, the expectations of this system will be substantially more complex than for a payroll system which has a lot of standard components, rather than many flexible elements required of a personalized education system.

The Ministry--and most of the other "stakeholders" except the BCTF--insist that the new system must be centralized.  Two reasons are given for this.  One is that BC has a centralized education funding system and the student information system must provide the information needed for the allocation of funds.

The other reason for centralization is that BC has a situation where increasingly students are cross-enrolled.  Because of this, the Ministry contends a central system is necessary to keep track of students where ever they are.  As an example, a secondary student might have four face-to-face courses at one school and four other Distributed Learning courses offered in the DL programs of three different public school districts and their biology course at the Christian Heritage DL school.  To give the students this flexibility, a centralized system is required to track them.

Neither of these, of course, is the only way of organizing a school system.  The information needed for a funding system does not require all the other personal and academic information about an individual student to be in one comprehensive database. Other provinces don’t have students enrolling in DL courses outside their school district, unless it is through the district making arrangements with another and thus don’t have to track on a provincial basis.

A number of other elements will particularly the raise eyebrows of teachers.

One, for example, is that the functional requirements document suggests direct parent/student access to a portal with information from the teacher "grade book.”  The name "grade book" itself suggests a traditional record-keeping system of summative marks rather than a flexible system of formative assessment and feedback.

The requirements document also indicates that data from the student information system would feed a data warehouse and that “analytics” tools would be provided.  The data in the warehouse could be accessed from the school, district or provincial level.

Built into the definition of requirements is an assumption that personalization will require that every student has their own student learning plan.   Students with special needs would have IEPs that are just more complex versions of the student learning plan, thus facilitating inclusion by eliminating the labels.  This suggests some fundamental shifts in support for students with special needs that need to be discussed as policy issues, not adopted through the design of a student information system.

These and many more issues deserve attention by more than IT specialists and others whose job is specific to the technology.  Every tool shapes the task and it is essential that all teachers pay attention to the shaping of a new student information system.