Perhaps you have developed several small databases to manage pupil data for specific purposes over the years.

In this case, you might be looking at reducing the number of databases - thus saving time and money keeping them up to date.

We can help like this:

• We will allow you to choose from our existing pupil modules - some may fit specific needs you have
• We will develop new modules to replace existing applications
• We will carry out the process of data integration
• You will end up with a centrally managed, robust platform of applications managing pupils
• You will also have all the benefits of a BSL approach - workflow, web access and automation

The need to gather and store data is increasing - as recent government guidelines show.

Not all suppliers react as fast to the market as you might like - especially the larger ones.

BSL have developed a large number of applications simply because a client expressed an interest. This approach continues - and we always need new clients!

We will develop applications specially for you, and integrate them with your existing core pupil database, if you like.

Alternatively we can provide an easy to use pupil database which does NOT suffer from the vagaries of data imported from schools. This will be kept in line with your core database, but will filter out the more glaring errors which creep in.

You may already have a core Pupil database - and be aware of some of the management issues surrounding such applications.

You may have come across the difficulties with managing the data needs of various interested parties.

For example - addresses from schools may not correspond with more recent information your pupil services teams have. The next upload may well wipe out what you have got - to the annoyance of existing data users.

By using BSL modules you can protect yourself from the worst problems - we connect directly to your core, but take regular snapshots before major uploads so that individual users can be informed of recent changes to core data. This information takes the form of an alert whenever the user works on a case - and they have the opportunity to accept the change - or to do something about correcting the new data if it is wrong.

We retain copies of earlier versions of core data so that users can compare. This is different from 'historical' data, which most systems now cope with - but with the assertion the core is CURRENTLY making about this child's address, full name or date of birth - and whether this has changed or not.

The current set of core pupil databases suffer from their own success.

By integrating data from various sources, such as PLASC, School exports and so on they can end up discarding good data in favour of bad.

Not many existing systems provide a vetting procedure that acts before data is uploaded.

Sometimes address data is discarded simply because there is no way to check it. Those of you who use the more common products may know what we mean.

We implement a mechanism for solving this problem.

In view of this we have developed a buffered core database which uses external data sources - but only after they have been cleaned up first. We treat your existing core database as the source - but make a copy which is 'safe' to use in casework. We would:

• Prevent address overwriting - SEN users get very upset if their letters go astray!
• Prevent data overwriting resulting in the loss of school leaving dates
• Perhaps collect parent and guardian data other systems avoid collecting
• Take the best information from your pupil core, and leaving out the less reliable data.

We manage data ownership effectively.

Some data 'belongs' to the core - results, absences, addresses and so on.

However, if a user knows that the core address is wrong - perhaps because they spoke to the parents that morning - and wishes to address a letter to them - they can request a data change, and perhaps the core data management team can make the change for them - and everything is OK......until the next data upload...

Can your existing system guarantee that this modified address will not be lost at the next data upload?

Neither can we - unless we supply your core pupil database - but by using our modules approach you can have some control over the ownership of data - and can implement our data ownership management strategy.

This would alert your module users to changes, allow them to 'retrieve' the correct data temporarily for their own use, and highlight the issue to your core data management team.

A similar approach applies to other significant data elements such as ethnicity, SEN Code of practice level, Exclusions and others.