Introduction
In the context of a major project subject to non-disclosure agreements, I decided to share certain aspects while preserving the confidentiality of the client and its ecosystem. This project represents one of the most important achievements of my career, hence my desire not to keep this significant experience silent.
In order to preserve confidentiality, I will speak in general terms, providing enough information to understand the scope of the project without revealing sensitive information that could identify the client or be exploited.
The client specialized in sending employees directly to end-users’ homes to perform a variety of operations, ranging from a few minutes to over an hour. However, due to the diversity of the tasks to be performed, the varying qualifications of the employees and the complex management of some demanding customers, advance planning of the employees’ days was essential. The objective was to allow each employee to perform the work corresponding to his or her skills at the customers’ premises, at the times when the customers were present at their homes.
Until now, this tour planning was done manually by employees, but the results were not satisfactory for all stakeholders. Clients complained about worker delays, workers complained about difficult schedules, and management complained about lack of profitability. In short, the schedules were causing separate problems for the three parties involved.
Mission
It is in this context that we intervened with a project aiming at automating 90% of the basic planning. This approach would allow employees in charge of scheduling to concentrate on the remaining 10%, i.e. the complex cases requiring human intervention. In this way, a human-machine collaboration would take place, where the scheduling employees could be much faster and more efficient in the basic tasks. They would then have extra time to solve tricky scheduling problems, such as a lack of qualified personnel for a specific tour.
It is important to emphasize that our goal was not to replace the scheduling staff in any way. They had irreplaceable expertise, but they also had to juggle a multitude of rules that made mistakes in the creation of schedules inevitable. Nothing is more efficient than machines to seamlessly apply hundreds of rules.
The project was deployed using a microservices approach, with each microservice specializing in a specific domain.
Data service
The first microservice, of a rather fundamental nature, acted as a bridge between :
- The client’s existing ecosystem, including its data and services
- The various microservices developed for the project
The purpose of this component was to normalize all relevant data into a unified structure, to serve as a single data source for all other microservices, as well as to function as a buffer or cache for the potential slowness or unavailability of the client’s other services in the event of an outage or update. It would store all the data needed for the other microservices in memory, knowing exactly how the data is related, its format, its structure, as well as how to access that data from their original services.
Planning machine service
The second microservice had the sole responsibility of creating schedules. It took as input various elements such as the addresses, the actions to be performed at these addresses, the time slots to perform these actions, as well as the employees with their skills, their working hours and their transport for the day (car, motorcycle, bicycle, public transport, etc.). At the end, it provided a schedule with the routes for each employee, optimizing the trips while respecting the many rules specified. Most of these rules were mandatory (e.g., an action requiring 2 employees could not be performed by only one), some were optional (e.g., not to exceed the intervention time generally expected for a type of task), while others were focused on optimization (e.g., minimizing the travel time between two interventions).
Human scheduling service
The third microservice, dedicated to the employees in charge of scheduling, allowed them to view, create, modify and delete schedules. They could either create the schedules manually, as they did before the project was implemented, or press a button to send the schedule to the second microservice. They then only had to check the result, manage alerts associated with the schedule generation (for example, the absence of a qualified employee for a specific action scheduled in the schedule) and resolve these issues.
In addition, two other microservices were developed to address the needs of employees visiting customers and the customers themselves. These separate portals provided a tailored user experience for each party, highlighting relevant information.
Conclusion
This project took over two years of full-time work and encompassed a larger number of microservices than those described above. It was one of the most interesting and complex projects I have had the opportunity to work on, rivaling the online mortgage project for CA next bank. Unfortunately, due to non-disclosure agreements, it is not possible for me to reveal any more information, otherwise I probably would have released a dedicated article to detail the structure of the project, the issues, and the end result.