From time to time, state education departments or group-level school bodies review the situation with the school admin systems employed at the schools under their authority. Sometimes, a decision is made to leave well enough alone but sometimes a decision is made to attempt to standardise some or all of the school administration software functions. The benefits of mandating a single system are:
(a) There’s an expectation that it will reduce costs in the long term
(b) Improve consistency across schools so staff don’t need to learn new skills when they transfer to a new school.
(c) Improves the ability for students and teachers to move seamlessly between schools or to study/teach at multiple schools (“breaking down the barriers between schools” so that each ‘school’ becomes a ‘campus’).
Let’s look at 3 approaches to the problem:
The default situation is that many different commercial software companies will cater to the needs of schools in the group. Other industries sometimes favour a winnowing out of small companies so that ultimately only large companies prevail, however, the Australian K-12 industry is characterised by a high level of fragmentation: a great many small software companies cater to the needs of Australian schools – there are perhaps 60 competing school administration software systems. One might naively think that this is inefficient: couldn’t those 60 companies pool their resources to produce one great product, instead of 60 good ones? In practice however, the schools appear to be getting a good deal from these small companies: the schools get a good level of support and have high levels of satisfaction.
Anecdotally, it seems that the smaller the company, the higher the level of satisfaction. A typical interaction with a small company is: “I have a problem!” “Ok, tell me what it is and I’ll turn my immediate attention to it!”. A typical interaction with a large company or in-house enterprise system is: “File a bug-report and one of our staff will [eventually] look into it”. Inside the large company, the ball bounces back and forth between different people whose areas of expertise eventually cover the areas needed to solve the problem.
Large companies also have the problem that every change must work with every one of their customers and every one of their legacy features, which makes the company reluctant to approve changes and costly for them to test changes. Also, large companies, especially ones with a high ratio of managers to engineers, often suffer from bureaucracy inflation: every time there is a problem, there is an urge to institute yet more processes to avoid it recurring.
One can call these various issues “diseconomies of scale”. It is perhaps surprising, but it is demonstrably true (because it has been done many times here), that one can produce a good student administration system with as little as 5 man years’ programming investment. ‘Good’ means that it makes customers happy and covers all the main areas: (a) attendance, (b) academic results, (c) enrolment data, (d) student contact details/medical info, (e) behaviour management, (f) timetable display, (g) class-list management, (h) teacher absences, (i) excursions.
Interoperability standards do enable many smaller companies to compete in a way that satisfies all stakeholders. For many years, departments/group bodies have been requiring the schools to submit various reports, usually using .csv or .xml files, and .csv/.xml files have been used between systems to interoperate with each other (e.g. school admin system with library system, or timetabling system). It may seem embarrassingly old-fashioned to use .csv or other flat files to get systems to communicate, but the practice is still widespread and actually quite successful – some might even ask “What problem is it exactly that you’re proposing to solve?”
A mention must be made here of the Schools Interoperability Framework (SIF). This is a standard that has come out of America and UK and has been adapted for Australian needs. It has met with some limited (so far) success here in Australia. The reason it has been a little slow to gain acceptance is because there is a high barrier to entry for software companies: the amount of effort required to implement it is large, e.g. one man-year, even with an existing framework implementation. The size of the specification document is enormous and it can take a 3-day workshop just for developers to learn how to do a “hand-shake” with the system. And for companies whose product is not implemented in either C# or Java, the 2 languages which currently have “framework implementations”, then implementing SIF is like building an enterprise system from scratch.
(There is also another standard called LISS, which aims to have the benefits of SIF without the complexity, however LISS is used in a much narrower context: intended primarily to connect timetabling systems with School Admin Systems.)
One criticism which can be made of this approach is that many school admin systems require a server to be placed in the school, and maintaining these servers is costly compared to the alternative of using a centrally-hosted or “cloud based” system. Some software companies will hotly contest this point, by claiming that it can be quite cheap to have a server per school if they are centrally administered and backed up – e.g. Sentral Education provides in-school servers for as little as $1500 per year, and at a stroke this solves problems of (a) bandwidth, (b) scalability and (c) what happens if the school loses their internet connection.
This approach involves evaluating all the software systems on offer, and picking the best one, performing some minimal customisations, and mandating it for all the schools in the group. Examples of this approach include OASIS (NSW) and MAZE aka CASES21 (Victoria).
In some cases, including CASES21, the product was taken in-house: source-code was given to the Department of Education and in-house staff were trained to support and develop it. This is a good way to benefit from (a) having a mature product as a starting point, and (b) the “natural selection” inherent in the open marketplace, (only the good products prevail), while (c) minimising the risk that a small software company proves unable to scale up their support function adequately quickly.
On the other hand, 2 disadvantages come to mind.
Firstly, over time, this product will become outdated. Presumably there are attempts to improve the product and keep it up-to-date with the latest technology and requirements, but these attempts typically do not keep pace with the amount of innovation that happens in the marketplace, because of the “diseconomies of scale” mentioned in the first section and also because of the complacency that inevitably follows a company gaining a monopoly position. OASIS is an example of a product that is now grossly out-of-date despite still being a requirement for NSW DET schools.
Secondly, if the goal is to “break down the barriers between schools so that there are only campuses, not schools”, then you might find there is no existing product which satisfies this requirement, or despite what the developers claim, the product does not do it as well as you might expect of a product designed from the ground up to be a “centrally hosted enterprise level web-based admin system”. Or that such systems that exist and can credibly make this claim, lack the rich feature set and customised graphical interfaces of older school admin software systems.
A third point is a warning: decision-makers at state or group levels are sometimes preoccupied with their own head-office reporting needs and issues to do with centralised hosting, and view everything else as a box to tick. On the other hand, stakeholders within the schools, (who vastly outnumber those in the head office) are usually more focussed on useability, detailed functionality and reputation for quality of support, and perceive vast differences between the various vendors on these metrics. You can get very different decisions made depending on which level is making the decision.
Approach 3: Build your own Enterprise-level School Admin System from scratch or off the back of an existing Business Intelligence product
Large consulting companies might make the claim that they have an existing “cloud-ready” generic product, which they can rapidly adapt to the requirements of the K-12 education sector. This approach is being tried in the South Australian Catholic Education system. One advantage of taking an enterprise system as a starting point is that a centralised payroll function (paying all the teachers out of the group head office) would be managed very effectively.
It remains to be seen how successful these types of projects are. The obvious disadvantage is that you are largely building a system from scratch, despite whatever claims the vendors make. A system of this sort typically looks and feels like an accounting system adapted for the education sector: it lacks the rich set of semantics and features behind each “business object”, and the screens all look alike (like you’re just looking at a bunch of relational database tables), and so if this system were to be evaluated by the school-level stakeholders alongside mature school admin software packages, then it would score the lowest on every axis except “enterprise-ready”. Is it really easier to turn an enterprise system into a good admin system than turning a good admin system into an enterprise system?
Also, the types of behemoth consulting companies which peddle these systems (Accenture, IBM, Oracle) have a very poor record of providing value-for-money or happy customers, especially as time goes on and the system needs to be further adapted.
I’m sure the readers will make up their own mind about what they think of each approach. All approaches are reasonable. My own opinion is that the first approach is best, followed by the second, followed by the third.
Dr Tim Cooper is co-founder of www.smartsgroup.com , a 150-personnel strong software development company. Also, as co-founder of Edval Timetables www.edval.com.au , he is an interested oberver of issues relating to School Admin Systems.