Implementing a Student Information System (SIS) for all types of programs and students
In my last post I discussed the impact of increased student mobility on Student Information Systems (or Student Records Systems). One of five main considerations when selecting a new SIS was the question if the system supports all types of students and all types of programs? Since modern integrated systems should support all types and therefore reduce the need for separate systems.
The time when the vast majority of applicants to a university was from the same country as the university or school (and often the same region) and had completed the required national high school level has passed a long time ago. In the past these students typically started and finished their academic career at one institution. They applied, were admitted, studied for 4 to 6 years and graduated. Most of today’s students apply and study at least twice: First a bachelor followed by a master program. This in itself already doubled the administrative burden on universities. The burden is actually much larger since master programs usually have some type of selection process (often different for students from the same institution compared to new applicants). Add to that and increased number of exchange students, increased full-time student mobility both nationally and internationally, the introduction of tuition fees in e.g. Germany and the U.K., different tuition fees for all programs, different fees for EU vs. non-EU students, etc. and it becomes clear that new processes and systems are required to reduce the administrative costs of running a university. This need is further increased due to recent budget cuts in most countries.
The increased diversity in programs and students has resulted in an equal variety in systems and processes at the universities, colleges and school. In some countries national systems for university applications exists which also have to be integrated with the university systems (such as UCAS in the U.K. and Studielink in theNetherlands). These systems do not replace the software used and institutions.
In SAP Student Lifecycle Management this complexity is reduced to a set of rules which is automatically generated based on three things:
- Which program is the student applying for?
- What is the previous education of the applicant?
- What are the personal characteristics of the student (nationality, age, residence, etc.)?
In other words: what do you want to do, what have you done and who are you?
This combination of program and personal information generates a profile which is used for the admission audit. This audit is basically a set of check boxes for each applicant. The number of conditions (check boxes) is small for a typical high school graduate who applies to a bachelor program. The list is long for a non-EU bachelor student who applies to a selective master program. It would include diploma evaluation, residence permit checks, motivation letters, perhaps an interview, language tests etc. none of which would apply to the student applying for a bachelor program in his own hometown.
The student information system should be capable to handle all these different applications via a workflow process which routes the applications to the right people at the right time. Based on their own expertise and role the administrative or academic staff deal with their part of the process without any paperwork being send around from office to office.