Improvements 79

The designed scheduling engine captures most important scheduling characteristics. However, the more accurate the input and scheduling decisions are made the better the output. In order to improve the scheduling engine there are two options, which are not mutually exclusive. The first option is to improve the accuracy of the current considered characteristics, the second option is to include more decisive characteristics.

The accuracy of the current considered characteristics is already discussed in Section 6.1. This section commences on those characteristics that are not yet included as they are not primarily decisive in scheduling, however they can improve scheduling process results when considered.

Relate to the expansion of included scheduling factors, one should always remember that the system captures a process that is subjected to personal preferences. In manual scheduling system, planners constantly make trade-offs which are based on a lot of characteristics, but many decisions are influenced by the person who schedules. The scheduling engine capture at least most influencing factors, but can be further expanded by a lot of factors. Together all those factors should simulate the decision making process of the planner. A down side on this is that the more characteristics included, the more difficult it gets to create a schedule. Each company should make a trade-off between the factors they want to include, such that the system provides acceptable results and is controllable.

The decisions made in the current scheduling algorithms are all local decisions. Each decision is made based on a timeframe, a list of events, and a list of resources. To narrow the view, the more chance to deviate from the path to optimality as interrelations are not considered. If the effect of scheduling a particular event, resource, or timeframe (and thereby removing that option from the list of options to be scheduled in the future) can be known beforehand, scheduling can be done more accurate as the effects can also be considered. For this matter a ‘look ahead’ functionality can be useful.

Examples for factors to consider as part of the ‘look ahead’ functionality are: - Time prior to the opening of a timeframe

Timeframes that are not open at the moment of scheduling are currently not considered for that scheduling decision. However timeframes that are about to open might be valuable option for scheduling. This can especially be the case in preparation times are involved.

For example, event A is available from 12AM to 5 PM and event B is available from 8AM to 14PM. The current time for scheduling is 11AM. According to the availability timeframe of events event A cannot be scheduled yet. However, travelling to event B might take more time than travelling to event A and waiting there until it is 12AM (i.e., the preparation time for event A equals at least 1 hour). Therefore decisions can better be made based on total preparation times (i.e., regular preparation time plus optional additional waiting time until timeframe opens) for each event.

- Time left within the given timeframe

In the current algorithms the number of days left to schedule the event are considered. However, the time within the current (daily) timeframe is not considered. As an extension also the time left within the current timeframe and possible effect of not selecting the current time for scheduling can be considered. For this the same further reasoning can be applied as above. In additional to these improvement suggestions, also the following improvement can be considered:

- Method for selecting a second resource

The current algorithm selects, if necessary, a second resource based on the ‘best alternative’ principle, in which the event and time first resource are already fixed. However, if that event is best to be scheduled another couple of resources might be a better option, although they are not the overall best option for that particular scheduling iteration. In order to improve the schedule engine, considering a resource couple while evaluating the priority value of a combination is valuable.

6.3.1. Further research

Within this research multiple solution approaches are discussed and evaluated, and based on our findings and the experiment results the application of Algorithm 4 provides a solid foundation for a scheduling engine. Gere (1966) states that the selected solution approach should include an answer to the question. As Algorithm 4 provides an answer to the question, the selected approach is useful. However, in addition we should ask ourselves what should be done, in case the result (i.e., schedule) is not good enough or if we think we can do better. The CPU times of Algorithm 4 within the test environment are much smaller than expected beforehand. Applying Algorithm 4 within a real life functioning system, considering real life data and all data sources, the CPU time might increase but still it is expected to be within acceptable boundaries. Due to the fact that the CPU times of Algorithm 4 are much smaller than expected beforehand, it is also worth considering applying an improvement method in addition to the current algorithm.

Likewise the wide range of constructive methods, there is a wide range of improvement heuristics. Simple improvement heuristics are for example r-opt. R-opt swaps r events and check whether the new solution is an improvement. If so, the new solution is accepted. If not, the original solution is kept. However, over the last years the application of metaheuristics as improvement method have increased popularity. The concept of metaheuristics is discussed in Section 3.3.2. Based on the earlier given descriptions as small desk study is performed into the successful application of metaheuristics as improvement methods, especially in scheduling. As a result of this search I recommend further research into the application of Tabu search.

Tabu search was first introduced by Glover around 1980. Over the years Glover successfully applied Tabu search on multiple scheduling problems. Through the development of Tabu search over the years, it has proven to find superior solutions and it has demonstrated to have advantages in the ease of implementation and in the ability to handle additional constraints (i.e., flexibility).

As mentioned in Section 3.3.2. Tabu search is a deterministic local search strategy that is able to escape from local optima. The schedule generated by Algorithm 4 can easily be used as a starting point for Tabu search. In order to improve the current solution, events are swapped and the new (neighbourhood) solution is stored on the Tabu list. The Tabu list prevents short-term cycling. The application of Tabu search increases the required running time, but is also expected to increase the quality of the results.