Latest Blogs

CELCAT Automation is a powerful tool that could bring significant benefits to both operational and institutional levels, improving not only processes, but also the quality of the timetable. However, it is by no means a simple process that creates the timetable at the press of a button; all the building blocks and rules for the timetable must first be in place, and expressed in a way that the scheduler (a computer algorithm) can use.

The following five points cover the high-level prerequisites for a move to Automation, and future blog posts will be exploring each one in more detail.

To successfully implement CELCAT Automation Course Scheduler, the institution must have:

• A clear understanding of what CELCAT Automation is, and what it is not. ‘Automation’ is often understood to mean the complete removal or replacement of human operators in a process - which this is not.
• A clearly defined set of unambiguous metrics that define the quality of the timetable along desired classification of subsets, to be encoded as constraints in Automation. These must be formalised in a timetable policy document, and agreed upon and supported by senior academic management.
• A clear and unambiguous set of roles and responsibilities for the team responsible for creating the timetable, and all staff who provide data and feedback to this team. It is vital that this be completely transparent and known across all levels of the institution, and particularly important if a central timetabling team will have authority to decide the time (as opposed to only the room(s)) for teaching events on the timetable.
• Sufficient time and resources to capture and verify complete and accurate resource data, templates, setting up of constraints, and to iteratively run automation, measure output against quality metrics and adjust underlying constraints and weights to achieve the desired outcomes. With some exceptions, full implementation of Automation to replace or supplement a manual approach requires at least 12 months, and often involves an initial year of parallel manual/automated timetabling before a final move to completion. In particular, the creation of templates is potentially resource-intensive and time-consuming, and should be carefully planned.
• A clear strategy for avoiding student clashes if Automation is used to assign times. If actual student data is to be used (usually only feasible for returning students), the deadlines and mechanisms for ensuring the timely availability of accurate and complete data must be incorporated into the project plan. For first-year students (and/or possibly for the entire timetable), it is vital that a data structure (usually CELCAT Groups) be agreed upon. This will model allowed combinations of modules/events in validated courses, so that the Course Scheduler does not create a clash between events that could potentially share students once enrolment starts.

Finally, a good litmus test for an institution’s readiness to implement Automation is simply the answer to the following question: When you use the Advisers, do they report back feasible slots, rooms and staff for your events? If the answer is ‘Yes’ then it’s likely you can encode those rules in Automation so that the Scheduler can (to grossly simplify) quickly run the Advisers for dozens (or even thousands) of events, and use the results to assign slots and/or rooms/staff to create a feasible timetable. If, however, the answer is ‘No’, then it’s likely that a lot of additional preparation must be done before Automation can be used.