# Data-Driven Decision Making in Maintenance Service Delivery Process: A Case Study
## 5 Case Study
### The Maintenance Service Delivery Stream  
#### 5.3.1 Cross Analysis  
An optimization model, customized to Beta's necessities, was developed in this phase. The need for such a solution stemmed from three factors:  
* too long time required to execute the scheduling,
* the necessity to involve two resources (i.e., an administrative employee and a technician) in the scheduling process: the administrative employee used to have skills in travel organization but not on technical problems and, therefore, the presence of a technician was always required
* suboptimal results achieved by Beta in carrying out maintenance scheduling in the original setting (e.g., intervention length wrongly esteemed and guided only by the human experience), affecting at business level Beta, who had to pay penalties for each intervention executed not respecting contractual clauses (e.g., intervention granted to be executed before a certain due date). Beta classified technicians into two categories: the ones able to deal with all the failures (mechanical and electronic) and the ones only able to deal with the electronic ones. The technicians' allocation task was not structured: if a technician who worked on the asset in the past was unable to intervene, the first one available was assigned to the request, even if not with the required competencies. In such a case, another technician, unable to travel, supported the selected technician remotely. The optimization model development was based on the idea that allocating the interventions to skilled technicians would result in a better, shorter execution of the intervention, and improved management of the resources. Following the analysis of historical service reports, two databases were created:  
* A database summarizing the typology of interventions usually executed by the technicians of Beta with the average execution time. * A database containing the skills required to execute the intervention according to the resolution typology (e.g., remote, on-field). \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **K-Nearest Neighbor** & **Discriminant Analysis** & **Neural Network** & **Multinomial Logistic Regression** \\ \hline
**Training time** & \textasci{-6.8} s & \textasci{-1.6} s & \textasci{-0.6} s & \textasci{-0.02} s \\
**Accuracy** & 100\% & 94.1\% & 100\% & 94.1\% \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison of the models. These databases should be constantly updated with new data and are used to feed the optimization model and match the intervention to be executed with the technician of Beta and the best resolution strategy (e.g., skills required, resolution approach, the technician assigned). Additionally, for Beta, they can be used to establish skill-based improvement plans for the technicians, allowing them to cover gaps and widen competencies. Since costs cover an important part of the decision-making process in the model, the objective function minimizes the total costs (e.g., intervention, travel, and penalty). Moreover, the new model overcomes one of the main limitations of the previous one by allocating multiple interventions in the same window (i.e., the time periods where a technician is free and, thus, available to execute it also considering the traveling time). The notation in the following was used to model the problem discussed hereabove:  
* \(R\): the set of intervention requests received by Beta. * \(M_{r}\): the set of modes that can be used to fulfill the intervention request \(r\in R\). * \(T\): the set of available technicians. * \(S\): the set of skills required by mode \(m\in M_{r}\). * \(W\): the set of windows available for each technician. Each window delimitates the period where the technician is available to execute the intervention. The problem desired to be modeled consisted in assigning an intervention request \(r\in R\) to be executed in a specific mode \(m\in M_{r}\) to a specific window \(w\in W\), associated with a single technician \(t\in T\) simultaneously minimizing the number of tardy jobs executed.