News & Events

In our previous blogs, we already introduced what scheduling is and why it is so important for almost any organization. However once an organization has decided to invest in a scheduling solution, there are many possible solutions in the market to choose from. How do you know which solution is the best solution for your organization? In other words, what are the characteristics of a good scheduling solution? In this blog, we try to give an answer to this critical question, by giving an overview of the critical characteristics of a good scheduling solution.

• User friendliness: obviously the solution should be user-friendly both to the people “being scheduled” and the schedulers, who are the power-users of the solution.
  • Scheduled colleagues: the solution should give a clear communication of what the schedule is and provide notifications of any updates to the schedule. It should also have functionality to allow people to make requests (e.g. request a day off) and access and check all information linked to the employee as an input for the scheduling process (like personal information, qualifications, pending, accepted and refused requests…​)
  • Schedulers: for schedulers the solution should allow an easy provisioning of all scheduling input information (via manual input, file uploads and/or via specific integrations), be easy to create schedules and to manually adapt these schedules; it should also provide easy and complete dashboards to follow-up on all scheduling KPIs.

• Cost price of the solution: obviously the price of the solution is a key factor. Typically the more-advanced and tailored to the specific needs of the sector and/or organization, the more expensive the solution will be.
  IIts important to also consider the full cost of the solution. Obviously there is the license or subscription cost, but this is only the tip of the iceberg. A scheduling solution comes also with an implementation cost, consisting of
  • Adapting the existing systems to provide the necessary data inputs (via manual, semi-automated or fully automated exports and/or real-time API integrations).
  • Training of people (especially the schedulers)
  • Deployment of the solution if it’s an on-premise solution (i.e. provisioning of the hardware and installation and configuration of the software)
  • Configuring the solution to the specific needs of the organization
  • Testing the solution

Additionally there is the run (operating) cost, which can be part of the subscription cost (in case of a SaaS solution), but if it’s an on-premise solution, we also need to account for infrastructure recurring costs (complex scheduling can require quite some computing power, resulting in high computing costs), costs for IT monitoring and debugging the application and its associated integrations, installing and regression testing patches and new releases provided by the vendor.

• Ability and ease to integrate the scheduling system with the rest of the software of the organization. This integration happens on 2 levels:
  • The data integrations required to receive all input information and to deliver the calculated schedule to other systems. These integrations can be fully automated via APIs or automated file handling, but it should also be possible to easily import and export files manually (like CSV, XLS, XML or JSON files). The ease of integration will be determined by the simplicity of the integration format imposed by the scheduling system, but also by the tooling to easily support different integration patterns (and potentially pre-built integrations with popular software packages).
  • The front-end integrations required to integrate the presentation layer within the rest of the organization. This consists of the possibility to easily setup SSO (ideally also with easy role management – authorisation), to expose certain widgets which can be integrated in other portals and the possibility to white-label (adapt) the front-end to the specific style (logo, colour, font style, terminology…​) of the organization. Some organizations might even want to create their own front-end, meaning the system should also expose well-documented and simple APIs which can be used by the organization to build their proprietary screens on.

• Time to market: how long does it take to deploy the solution within the organization. This will depend on the user friendliness (how much training is needed), the deployment model (on premise installation versus SaaS model), the required integrations and configurations…​

• Flexibility of the system: obviously the scheduling system will evolve with the organization. This means regularly small configuration updates will be required to adapt the scheduling system to new rules/constraints, new strategic directions, new processes and organizational structure…​
  Some typical adaptations will be:
  • Configuring new types of constraints
  • Fine-tuning the scheduling process to adapt the importance gives to certain constraints and objectives
  • Setting up new types of scheduling requests, e.g. at a school, it might be interesting that the same scheduling solution can be used for rostering of day-to-day schedule, but also the exam rostering, the attendance of teachers during play-breaks and before and after school, possible role distribution for specific fund-raising activities (like school party, open door day…​). Ideally the scheduling solution should be able to accommodate all those different scheduling processes.

• Accuracy of the scheduling outcomes. This means how optimal is the calculated schedule in finding the optimal value for the cost function, taking into account all elements in the scheduling process. Many scheduling solutions will have limitations on the number of elements that can be considered and many solutions will stop in local minima of the cost function. A good scheduling solution should avoid being trapped in local minima and identify the absolute minimum of the cost function. At the same time, the solution should also take robustness of the schedule into account, i.e. avoid that unforeseen events, which have a high probability to occur (e.g. illness of personnel or broken material) have a too high ripple effect on the rest of the schedule.
  Finally the scheduling should also take into account a fair distribution (over time) of favorable assignments across resources. This requires that resources who got an unfavorable schedule in the last scheduling period(s) should get priority in the new scheduling period to get a desirable allocation.

• Speed at which a schedule can be calculated can also be essential. In certain sectors (which are very time-critical), it should be possible to (re)calculate the schedule in a very short time to react to changing conditions. Usually a faster calculation will however result in a lower accuracy of the calculated schedule, but this trade-off will be less applicable in a good scheduling solution, i.e. good scheduling solutions
  • will reach accurate solutions faster, thanks to more advanced mathematical models, which can reach target solutions with less computations.
  • give control to the user, which level of accuracy is required. This gives the user the option to take a conscious decision in the dilemma between speed and accuracy.
  • can make early predictions, allowing to identify issues (e.g. bottle necks) with the schedule early in the process (without having to recalculate the full schedule). This allows the schedulers to adapt/correct specific inputs quickly, without having to wait for the full calculation.
  • are highly scalable, i.e. they have both horizontal and vertical scalability, which is not straightforward due to the nature of the calculations done within a scheduling solution.

• Release cycle, i.e. how much is the system still expected to evolve and which gains versus efforts will those new releases bring to the organization, i.e.
  • How fast can specific demands of the organization be taken into account?
  • How much can the organization influence the future release content?
  • How many releases per year does the software provider foresee?
  • Is there a clear communication of the release content upon the delivery of a new version?
  • Which impact does a new release have for the organization? Is there any downtime (during/outside business hours, impacts for running scheduling processes…​)? What is the procedure for the installation of a release?
  • Is backwards compatibility ensured? Are there any configurations which need to be redone after an installation of a product release?
  • Is each release properly tested by the vendor (potentially even on specific configurations of each customer) before being delivered? Which degree of regression testing is expected of the organization and how long does this take?

• Support and services offered by the solution provider:
  • Which deployment model is supported, i.e. on-premise installation and/or SaaS?
  • Are tailor made development requests supported? And are those integrated in the standard product of the vendor?
  • Does the vendor offer consulting services, like integration services, customization services, training…​?
  • Is Scheduling as a Service supported by the provider? This can be interesting especially for more exceptional scheduling exercises happening only a few times per year or even less.
  • What is the level of Customer Support? Is there 24/7 customer support? What is the reaction time to a service request? What is the average resolution time of a service request? Can those KPIs be guaranteed in an SLA?
    …​

• Risk of the organization and solution, i.e.
  • How financially viable is the vendor?
  • Will the vendor still be around in 3-5 years? And if, will the vendor still support the proposed scheduling solution?
  • How strong is the vendor lock-in, i.e. what is the simplicity to switch to another scheduling system (reuse of integrations, possibility to easily export all data stored in the scheduling system…​)
  • Are there any credentials (customers) in production? Similar in size? With similar company culture?
  • What is the technical architecture of the solution? Is the solution technically viable for upcoming years? Is the solution scalable with the ambitions of the organization?
  • Does the vendor target a specific market (customer) segment? If so, does the organization fit with it today and also in 5 years (if the company’s business strategy unfolds)?
  • Are data safety (GDPR) standards sufficiently guaranteed (like 2FA authentication, encryption of all data-at-rest, usage of HTTPS for all end points, execution of regular security audits…​)
  • Is the availability and stability of the solution sufficiently ensured, e.g. support of multi-level back-up strategy, support of DRP…​

The above criteria show that the choice of a good scheduling solution is not something to take too lightly. Instead it should be handled as a long-term strategic decision for which a good comparison and due diligence of the different solutions on the market should be made. A good practice is to define a scoring matrix of all above criteria and define upfront a weight to each criterium. This allows to score different solutions on the market in a fair and objective way and choose wisely the best solution for the specific situation (and use cases) of the organization.

Photo by Markus Spiske on Unsplash