CA3136409A1 - Systems and methods for automated modeling of service processes - Google Patents

Abstract

A method for automatically generating a model of a service process is provided. The method includes: receiving historical event data; processing the historical event data to extract system occupancy enhancing the historical with such system occupancy information; separating the enhanced historical event data into a training dataset and a testing dataset; building a queueing network model by extracting activities and estimating pathways and routing probabilities from the training dataset; and enhancing the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways. A corresponding system and computer-readable medium are also provided.

Description

SYSTEMS AND METHODS FOR AUTOMATED MODELING OF SERVICE
PROCESSES
TECHNICAL FIELD
The present disclosure generally relates analyzing service processes, and more specifically to methods and systems for automated modeling of processes to allow making descriptive, comparative, predictive and prescriptive analytics thereof.
BACKGROUND
Analytical and simulation models have been used extensively to analyze service systems. Given that traditional analytical techniques usually only work for relatively simple systems, simulation modeling is often the only feasible solution for real-life processes. However, there are many challenges with simulation models that are often seen as fatal in modern fast-changing service systems.
One challenge is missing log data, which is a very common occurrence. The fact that missing data affects model validation means insights produced by the model cannot be trusted.
Another challenge relates to long development times. Due to the complexity of the service systems, it generally takes a long time to produce a useable model.
Such developments times are often measured on the order of months for large zo processes. As such, the process being modeled will likely have changed by the time the model is complete.
A further challenge relates to non-unique representation. Since simulation models are constructed manually, two expert analysts may create very different models for the same system. This reduces trust in the model and causes ambiguity as to which of the models is correct, especially when more than a single performance measure is being used.
There is therefore much room for improvement.

Date recue/date received 2021-10-28 SUMMARY
Systems and methods are described for creating accurate service system representations automatically via data-driven methods. The mapping from data to the model can be well defined and transparent. The resulting models can be generative in nature, i.e., they can generate new data that resembles the actual data coming from the system under different interventions. Thus, simulations, automatically created based on the original data, can serve as a test bed to study the impact of different interventions, enabling comparative analytics. The simulation can be developed, verified, and validated, using machine learning models that guide the internal sampling process. By using approximations from queueing theory, the service system's behaviour can be estimated with adequate levels of accuracy even when data is missing or inaccurate.
According to an aspect, a method for automatically generating a model of a service process is provided. The method includes: receiving historical event data corresponding to activities processed by a service system, said historical event data comprising a plurality of events and, for each event, values corresponding to a plurality of attributes, said plurality of attributes including at least a participant identifier, an activity identifier and a timestamp; processing the historical event data to extract system occupancy information and enhancing the historical event data zo by adding the system occupancy information as at least one additional context attribute; separating the enhanced historical event data into a training dataset and a testing dataset; building a queueing network model by extracting activities and estimating pathways and routing probabilities from the training dataset; and enhancing the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways.
According to an aspect, a system for automatically generating a model of a service process is provided. The system includes: an input module configured to receive historical event data corresponding to activities processed by a service system,

2 Date recue/date received 2021-10-28 said historical event data comprising a plurality of event and, for each event, values corresponding to a plurality of attributes, said plurality of attributes including at least a participant identifier, an activity identifier and a timestamp; a data enhancement module configured to process the historical event data to extract system .. occupancy information and enhance the historical event data by adding the system occupancy information as at least one additional context attribute; and a model learning module configured to separate the enhanced historical event data into a training dataset and a testing dataset, the model learning module comprising a process discovery submodule configured to build a queueing network model by .. extracting activities and estimating pathways and routing probabilities from the training dataset, and a queue mining submodule configured to enhance the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways.
According to an aspect, a non-transitory computer-readable medium is provided.
The computer-readable medium has instructions stored thereon which, when executed by a processor of a computing system, cause the computing system to:
receive historical event data corresponding to activities processed by a service system, said historical event data comprising a plurality of events and, for each event, values corresponding to a plurality of attributes, said plurality of attributes zo including at least a participant identifier, an activity identifier and a timestamp;
process the historical event data to extract system occupancy information and enhance the historical event data by adding the system occupancy information as at least one additional context attribute; separate the enhanced historical event data into a training dataset and a testing dataset; build a queueing network model .. by extracting activities and estimating pathways and routing probabilities from the training dataset; and enhance the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways.

3 Date recue/date received 2021-10-28 BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram illustrating a system for automatically modelling a service process, according to an embodiment.
Figure 2 is a schematic illustrating exemplary event data that can be provided to the system of Figure 1.
Figure 3 is a table illustrating exemplary event data contained within an event log of an emergency department service system.
Figure 4 is a flowchart illustrating a method for automatically modelling a service process that can be carried out by the system of Figure 1, according to an embodiment.
Figure 5 is a flowchart illustrating a method for predicting impact of interventions on a service process, according to an embodiment.
Figure 6 is a flowchart illustrating a method for optimizing intervention in a service process, according to an embodiment.
DETAILED DESCRIPTION
In the foregoing description, systems and methods will be described for automatically modelling and analyzing service processes. Service processes can generally be modelled as queueing networks which comprise a plurality of interconnected queueing nodes or stations. In such models, jobs or customers zo arrive at a queue, are processed at the queue (i.e. are provided a service via a resource), and then depart from the queue. Depending on the nature and capacity of the queue, the job or customer may need to wait when arriving at a queue before it is their turn to be processed, and/or it may take some time to process the job or customer once it is their turn.
As can be appreciated, a service process can correspond to any process implemented by a service system that provides one or more services using

4 Date recue/date received 2021-10-28 available resources. As such, system elements corresponding to jobs/customers, resources, stations/services, etc. can vary depending on the nature of the service system. Accordingly, in the following description, terms such as "job", "customer", "resource", "service", "station", etc. are intended to describe generic elements of queueing networks, and are not intended to refer to a type of service system in particular. Moreover, similar terms such as "job"/"customer, or "service"/"station"/"node" will be used interchangeably.
In the following description, reference will be made to "events" occurring within a service process. It should be appreciated that an event can correspond to any transaction within a queueing network that relates to how a customer travels through the queueing network and/or how the customer is processed at any given node. An event can, for example, correspond to a customer arriving at a node, a customer being processed at a node, and/or a customer leaving a node, among other possibilities.
With reference now to Figure 1, an exemplary system 1 for automatically modelling a service process is shown according to an embodiment. In the illustrated embodiment, the system 1 comprises an input module 3, data preprocessing module 5, data enhancement module 7, model learning module 9, simulation module 11, diagnostics module 13, and an output module 15. As can be appreciated, these modules can comprise software modules implemented on programmable devices, such as one or more physical or virtual computers comprising a processor and memory. In some embodiments, one or more non-transitory computer readable media can comprise instructions that cause a processor to carry out steps which implement the modules. It is appreciated, however, that other configurations are possible. Broadly described, the system is configured to receive event data 50 occurring as part of the service process, and automatically generate therefrom a model 60 that describes the service process and that can be used to perform descriptive, comparative, predictive and/or prescriptive analytics.

5 Date recue/date received 2021-10-28 The system 1 is configured to receive event data 50 via input module 3. As can be appreciated, event data 50 can be stored on a data source 17, such as an external database. Accordingly, input module 3 can be configured to interface with data source 17 in any suitable manner to receive event data therefrom 50. The received event data 50 can subsequently be processed via data preprocessing module 5, data enhancement module 7, and model learning module 9 to produce a candidate model therefrom which describes various characteristics of the service process.
The operations carried out by these modules to produce the candidate model are described in more detail herein below.
The system 1 further includes a simulation module 11 that is configured to carry out simulations using the candidate module to predict the behaviour of the modelled service process subject to different inputs. Moreover, a diagnostics module 13 is provided to allow calculating performance measures to allow validating performance of the candidate model. A validated model can subsequently be output via output module 15 as a model 60 that can be used for subsequent comparative and prescriptive analytics. As can be appreciated, the output module 15 can be configured to output module 15 in different forms. For example, in some embodiments, the output module 15 can comprise an interface allowing the model 60 to be provided to other systems for further analysis. In some embodiment, the output module 15 can comprise a user interface, for example to output the model 60 and/or performance measures calculated therefrom for viewing by a user on a display device.
In more detail now, the event data 50 that is processed by system 1 can, for example, be generated by computing systems that gather transactional data on objects, events, and activity that is processed by a service system implementing the service process. In an embodiment, the event data 50 can correspond to granular transactional data that can be found in event logs. As can be appreciated, event logs can be stored in computing systems using different storage mechanisms. For example, event logs can be stored in a database that can comprise one or more related tables. In such tables, each line or row can

6 Date recue/date received 2021-10-28 corresponds to an event, while each column corresponds to an attribute that has a value that describes characteristics of the event. Such characteristics can, for example, be used as features to train machine learning models, as will be described in more detail hereinbelow. Accordingly, in the following disclosure, the term "row" will be understood to refer to an individual event recorded in event data 50, and the term "column" will be understood to refer to an attribute describing a characteristic of an event that can correspond to a feature for training a machine learning model.
With reference to Figure 2, exemplary event data 50 that can be received by system 1 is shown according to an embodiment. As can be appreciated, event data 50 can allow inferring the structure and dynamics of the service process from which such event data was collected. To allow making such inferences, the event data 50 can comprise rows for a plurality of recorded events 51 and, for each row, columns comprising at least a participant 53 identifier, an activity identifier 55 and a timestamp 57. In some embodiments, the event data 50 can further include context data 59.
The participant identifier 53 uniquely identifies a participant that is involved in the event 51. Such a participant can correspond to a resource that is providing a service and/or to a customer that is receiving the service. As can be appreciated, any suitable identifier can be used to uniquely identify a participant. In some embodiments, the participant identifier 53 can comprise a number attributed to a given participant that is different from numbers attributed to other participants. As an example, if the service process corresponds to operating an emergency department in a hospital, the participant identifier 53 can comprise a case identifier, which is a unique number attributed to a patient during a specific visit to the emergency department. As another example, the participant identifier 53 can comprise a resource identifier, for example identifying a doctor or a nurse providing a service to the patient as part of a given event. As can be appreciated, a plurality of participant identifiers can be provided if there are a plurality of participants involved in an event. For example, where an event corresponds to a customer

7 Date recue/date received 2021-10-28 receiving a service from a resource, a first participant identifier can be provided for identifying the customer, and a second participant identifier can be provided for identifying the resource.
The activity identifier 55 uniquely identifies an activity concerned by the event 51.
Such an activity can, for example, be associated with an individual service that is provided to a customer as part of the service process, or a station that the customer visits to receive such service. As an example, if the service process corresponds to operating an emergency department in a hospital, the activity can be an administrative or a medical service provided to a patient, for instance registration, admission, vital signs measurement. Depending on the nature of a service, one or more activities can be associated with such service. For example, an activity can correspond to a service as a whole having been provided to a customer, such as a patient having proceeded with registration in the emergency department.
As another example, a first activity can correspond to a start of a service being provided to a customer, such as the emergency department admissions process starting for the patient, and a second activity can correspond to an end of the service being provided to the customer, such as the admissions process ending for the patient. As can be appreciated, any suitable identifier can be used to uniquely identify an activity. For example, the activity identifier 55 can comprise a .. number attributed to a given activity that is different from numbers attributed to other activities. As another example, the activity identifier 55 can comprise a label that is attributed to a given activity, such as a description of the name of the activity, that is different from labels attributed to other activities.
The timestamp 57 can provide an indication of the date and/or time at which the .. event occurs. As can be appreciated, the timestamp 57 can be provided in any suitable format. For example, the timestamp 57 can comprise a string of characters that conforms to any date and/or time format defined in the ISO 8601 standard, or can comprise a natural number that represents the Unix time, which is the number of seconds that have elapsed since 1 January 1970 at midnight UTC.

8 Date recue/date received 2021-10-28 The context data 59 can comprise additional columns that reflect characteristics of the participants (i.e. customers and/or resources) and/or of the activities (i.e.
services provided to customers by the resources) concerned by an event 51. For example, if the service process corresponds to operating an emergency department in a hospital, the context data 59 can comprise columns including characteristics of the patient participating in an event, such as the patient's age, gender, address, etc. The context data 59 can further comprise columns including characteristics of a resource, such as information about the doctor or nurse providing service to the patient. As can be appreciated, columns of context data can correspond to static parameters in that their value does not change throughout the service process. Columns of context data can alternatively correspond to dynamic parameters in that their values are subject to change during the service process. An example of static parameters is a patient's age or gender which will remain the same throughout a visit to the emergency room. An example of a dynamic parameter is an assigned triage score, which may change as the patient is subjected to different activities in the emergency room.
With reference to Figure 3, an exemplary event log of an emergency department in a hospital is shown according to an embodiment. In the illustrated embodiment, the event log comprises event data 50 stored in a database and structured as a table. Each line or row of the table corresponds to an event 51, and seven columns are provided, each corresponding to an attribute that describes characteristics of the event. The first column 210 corresponds to a participant identifier 53. In the present embodiment, the participant identifier 53 is a case ID that comprises a number uniquely identifying a patient during a specific visit at the emergency department. The second column 220 corresponds to an activity identifier 55. In the present embodiment, the activity identifier is an event name that comprises a unique label describing a service in the process. The third column 230 corresponds to a timestamp 57. In the present embodiment, the timestamp 57 is a string of characters representing the time at which the event occurs in the format HH:MM:SS. As can be appreciated, columns 210, 220, 230, respectively corresponding to participant identifier 53, activity identifier 55 and timestamp 57,

9 Date recue/date received 2021-10-28 can comprise a minimum amount of data to describe the path of a patient through an emergency room process. For example, it can be seen that the patient corresponding to the case identifier 111 was provided the service named "Registration" at 7:30:04, was provided the service named "Nurse_Admission_Start" at 7:35:52, was provided the service named "Nurse_Admission_End" at 7:47:12, etc. A similar sequence of provided services can be followed for other patients associated with other case identifiers.
Although not illustrated, it is appreciated that a resource identifier can also be associated with each activity.
The illustrated event log further includes additional columns 240 correspond to context data 59. In the present embodiment, the context data 59 comprises static parameters describing characteristics of patients, such as the age and gender of the patients. The context data 59 further comprises parameters describing characteristics of the services provided to the patient, such as the diagnosis attributed to the patient, and the outcome of the patient's visit. As can be appreciated, although such context data may not be required to describe the path of patients though the emergency room process, it can be used to predict various performance indicators, including length-of-stay of the patients, system utilization, etc.
With reference now to Figure 4, an exemplary method 100 for automatically generating a model of a service process is shown according to an embodiment.
As can be appreciated, the method 100 can be carried out via various modules of the above-described system 1. The method 100 can comprise a first step 110 of receiving, via input module 3, event data 50 describing events processed by a service system implementing the service process. Such data can be referred to as "historical" event data in that it corresponds to a record of actual events processed in the past by the service system, and can be distinguished from "simulated"
event data that merely seeks to emulate how the service system would behave.
Date recue/date received 2021-10-28 As can be appreciated, depending on the storage scheme used, event data 50 can be received in different forms. For example, event data 50 can be received in the form of an event log corresponding to a table in a database. In such an embodiment, receiving the event data can comprise connecting to the database and/or importing a table from the database corresponding to the event log. The columns of the table can be manually annotated by a user to indicate which columns correspond to the participant identifier, the activity identifier, and the timestamp. The columns can further be manually annotated to indicate additional context information. In some embodiments, the event data can be distributed among a plurality of tables, and receiving the event data can comprise combining or flattening data from the plurality of tables into a single table.
A second step 120 of the method 100 can comprise preprocessing the event data 50 via data preprocessing module 5. As can be appreciated, any suitable preprocessing steps can be applied. In the present embodiment, the data preprocessing 120 comprises four sub-steps (which can be implemented via sub-modules of preprocessing module 5), namely data cleaning 121, type conversion 122, removing infrequent events 123, and computing temporal relationships 124, although it is appreciated that other preprocessing steps are possible in other embodiments.
zo Data cleaning 121 can comprise completing or removing incomplete data. An event recorded in the event data 50 can have one or more missing values if does not specify a value in one of its columns, such as a participant identifier, an activity identifier and/or a timestamp. In some embodiments, events with a missing value can be removed from the event data 50. I other embodiments, a user can be provided with a request to fill in the missing value, or ignore the missing value if it isn't critical. For columns that represent values with a known type or domain, a value that is not of the required type or in the appropriate domain can be treated in the same way as a missing datum. In some embodiments, an outlier value can be treated in the same ways as a missing value. As can be appreciated, well-known anomaly detection methods can be applied to the values to identifier outlier Date recue/date received 2021-10-28 values. For example, a probabilistic model can be created from the values, wherein a value that has a probability according to the model below a given threshold is considered an outlier value.
Type conversion 122 can comprise encoding certain values into a format that can be exploited by a machine learning module. For instance, if a column corresponds to a categorial attribute, such as a text label, the values of such attribute can be encoded before being submitted to machine learning modules. In some embodiments, if a categorial attribute can take a number of values, dummy attributes can be created corresponding to the number of values minus one. The categorial attribute can then be removed from the event data 50 replaced by the dummy attributes. Other approaches are also possible. For example, if a categorial attribute can take a number of values, one-hot attributes can be created for each of the possible values.
Removing infrequent events 123 can comprise removing, from the event data 50, rows corresponding to activities and/or sequences of activities that occur relatively infrequently. For example, a threshold can be provided or computed corresponding to a number of occurrences of activities or sequences of activities that is considered rare. The events corresponding to the activities and the sequences of activities that occur a number of times that is below the threshold can removed from the event data 50. In some embodiments, the threshold can be computed by attempting to generate a model of the service process with different thresholds and selecting the threshold that creates the model with the best performance as defined hereafter.
Computing temporal relationships 124 can comprise computing relationships between different activities in the service process. For example, pairs of activities that directly follow one another in the event log can be identified and the frequency thereof can be computed.
A second step of the method 100 can comprise enhancing data 130 via data enhancement module 7. During this step, new attributes can be created from the Date recue/date received 2021-10-28 event data 50 to describe system occupancy. The system occupancy can correspond to a measure of how many participants are currently in the service system and can, for example provide indications of congestion, trend and seasonality in the service process. The new attributes can then be added to the event data 50 as new columns to produce enhanced event data 50'. In this fashion, the model of the service process created from the enhanced event data 50' can be aware of the new attributes/features relating to system occupancy. As an example, correlations between sojourn times (total length of stay durations) of patients that arrive during overlapping periods in time (e.g., the same hour) can be computed.
This correlation can be added as a feature that will make the model aware of state and system congestion. As another example, if patients are not-pre-assigned to groups, patients can be grouped into clusters by their similarities in length-of-stay.
Subsequently, the number of patients in each cluster over time can be added to the data as part of an additional enhancement step. In some embodiments, the new attributes describing system occupancy in the service process can be computed according to the methods described in Senderovich, A., Beck, J. C., Gal, A., & Weidlich, M. (2019), "Congestion graphs for automated time predictions", Proceedings of the AAAI Conference on Artificial Intelligence, 33(01), 4854-(hereinafter "Senderovich et al., 2019"). In particular, using modified queueing network mining techniques, a congestion graph can be created to represent a flow of resources in terms of events and labelled with performance information that is extracted from the event data 50. The extraction of the performance information can be grounded in a state representation of an underlying queueing system.
The labels can then be transformed into attributes that can be added to the event data 50 to produce the enhanced event data 50'. Using such techniques, system occupancy -related attributes such as the number of patients in the system, their elapsed time, and their inter-arrival time can be added as features to help define the model of the service process.
A subsequent step in the method 100 can comprise model learning 140 in which a model of the service process is generated from enhanced event data 50' via model learning module 9. In the present embodiment, the enhanced event data 50' is Date recue/date received 2021-10-28 separated into two distinct sets of data: a training set 50a and a testing set 50b. As can be appreciated, the training set 50a can be used during the model learning step 140 to build the model of the service process, whereas the testing set 50b can later be used to evaluate and/or validate the model, for example as part of the diagnostics step 160 that will be described in more detail hereinbelow.
Separating the enhanced event data 50' can be carried out in any suitable manner. For example, a predefined proportion of the resources can be selected randomly such that the events associated with the selected resources are placed in the training set 50a, and the remaining events are placed in the testing set 50b. In some embodiments, k-fold cross-validation can be used. For example, in 10-fold validation, ten training sets 50a and ten testing sets 50b can be prepared, in such a way that each one of the training sets 50a contains 90% of the events and each one of the testing sets 50b contains the remaining 10% of the events, and that none of the ten testing sets 50b contain shared events.
In the present embodiment, model learning 140 is carried out in two sub-steps:
a process discovery sub-step 140a and a queue mining sub-step 140b. The process discovery 140a sub-step can be carried out on a corresponding sub-module of model learning module 9, and generally involves estimating pathways and routing probabilities of activities from the training data 50a to produce a pre-model.
The queue mining sub-step 140b can be carried out on a corresponding sub-module of model learning module 9, and generally involves enriching the pre-model by fitting a plurality of queueing building blocks, as will be described in more detail hereinbelow.
As part of the process discovery sub-step 140a, a list of activities can be extracted from the appropriate column of the training data 50a. In some embodiments, an additional activity can be created to correspond with the beginning of the service process, which is used by all customers and precedes all the other activities in sequences, and an additional activity can be created to correspond with the end of the service process, which is used by all customers and follows all the other services in sequences. A pre-model can subsequently be estimated from the Date recue/date received 2021-10-28 training data 50a to describe all possible pathways between the extracted activities and their corresponding routing probabilities.
As can be appreciated, the pre-model can be constructed using any suitable format. For example, in some embodiments, a directed graph can be created. The .. directed graph can include one vertex for each one of the activities extracted from the training data 50a, and a plurality of arcs connecting the vertices according to the different routing possibilities. Different process mining techniques can be used to discover the arcs.
In some embodiments, the arcs can be discovered by applying the techniques 3.0 described in Senderovich, A., Weidlich, M., Yedidsion, L., Gal, A., Mandelbaum, A., Kadish, S., & Bunnell, C. A. (2016), "Conformance checking and performance improvement in scheduled processes: A queueing-network perspective", Information Systems, 62, 185-206 (hereinafter "Senderovich et al., 2016").
Using such techniques, a partial ordering of the activities can be inferred from the sequence of activities that are observed in the training set 50a. A
qualitative constraint network using an interval algebra, such as Allen's interval algebra, can be instantiated from the partial ordering, where each one of the services corresponds to one interval. This can allow discovering a total ordering on the lower and upper bound of the intervals, for example by computing the closure of zo the qualitative constraint network under relation composition. The arcs can be created from the total ordering. In some embodiments, where an activity is followed by a plurality of activities that may be used simultaneously, an additional vertex corresponding to a fork can be inserted in the directed graph, and where a plurality of services is followed by one activity that can start only once the plurality of activities has completed, an additional vertex corresponding to a join can be inserted in the directed graph. In some embodiments, where an activity is followed by a plurality of activities that may not be used simultaneously, the probability that each one of the plurality of activities follows the activity is computed and added to the directed graph, for example as an arc weight. In some embodiments, the directed graph with weighted arcs can be a probabilistic fork/join network.
Date recue/date received 2021-10-28 In some embodiments, the pre-model can be further processed in order to filter our rare activities, paths and/or transitions. For example, the pre-model can be analyzed in order to identify vertexes that are visited infrequently in the training data, for example below a predetermined threshold (such as an absolute threshold or a threshold relative to other vertexes), and such vertexes can be removed from the pre-model. Similarly, the pre-model can be analyzed in order to identify arcs or transitions between vertexes that are followed infrequently in the training data, for example below a predetermined threshold (such as an absolute threshold or a threshold relative to other arcs or transitions), and such arcs or transitions can be .. removed from the pre-model. If the directed graph of the pre-corresponds to a Markov chain, the arc or transition can be removed by setting its probability to 0, for example.
Once the pre-model has been created, the queue mining sub-step 140b can comprise applying queue mining techniques to fit a plurality of building blocks from the training data 50a to enrich the pre-model. The building blocks can be fitted, for example, using the techniques described in Senderovich et al., 2016. In the present embodiment, a total of eight possible building blocks 141-148 can be fitted, but it is appreciated that different building blocks and/or combinations thereof can be fitted in other embodiments. The eight building blocks 141-148 will be described in more detail hereinafter for exemplary purposes. For simplicity, they will be referred to as first, second, third, etc. building blocks, but it is appreciated that they are not being presented in any particular order. As can be appreciated, each building block can correspond to a submodule of the model learning module 9, and can be applied independently from one another.
In the present embodiment, a first building block 141 can relate to external constraints or delays. As can be appreciated, depending on the nature of the service process, factors that are external to the service process may introduce delays in the provision of services that are reflected in the training data 50a. As an example, if the service process corresponds to operating an emergency department in a hospital, such external factors can correspond to external Date recue/date received 2021-10-28 consults, bed blocking, and ambulance diversion, among other. As can be appreciated, consultations by professionals outside of the emergency department are external to the patient flow process in the emergency department yet can introduce delays therein. When a destination ward outside the emergency department is full, departure of patients from the emergency department can be delayed. Similarly, when external decisions are made to temporarily divert ambulances, the patient arrival process can be affected. Given that such constraints are exogenous to the emergency department service process, the pre-model can be adjusted such that the model of the service process reflects the effect .. of such external constraints.
As can be appreciated, different steps can be carried out to fit the first building block 141 and adjust the pre-model to account for impacts of external constraints or delays. In an embodiment, a first step can comprise discovering external constraints that can have an effect on the training data 50a, for example based upon user input or additional information (knowledge or data). A second step can comprise adjusting the model to capture the effects of such constraints on the service process. One example in the context of emergency departments is specialist physicians. In the first step, it can be observed that emergency patients seen by a specialist experience higher waiting time. As specialists are not under direct supervision of the management of the emergency department, their service is an exogenous constraint on the system. In the second step, the specialist service can be added to the visit characteristics, for example as one or more additional context data attributes in the training data 50a. These additional attributes can later be used as features feeding machine learning models that describe customer processing times and routing.
A second building block 142 can relate to the structure of the queueing network describing the service process. As can be appreciated, fitting this building block can allow discovering the queueing network, including relevant stations therein. In a first step, historical visits of customers to stations can be identified. In a second step, unique stations that are visited above a predetermined frequency threshold Date recue/date received 2021-10-28 can be integrated into a network of queues defining the structure of the queueing network. Similarly, unique stations that are visited below the predetermined frequency can be omitted (i.e. removed) from the queueing network structure.
Fitting this building block can further comprise discovering relevant pathways and/or transitions in the queueing network. Pathways and/or transitions between stations can be identified from historical visits, and pathways and/or transitions that are followed above a predetermined frequency threshold can be integrated into the network of queues. Similarly, pathways and/or transitions that are followed below the predetermined frequency can be omitted (i.e. removed) from the queueing .. network structure, for example by setting their probability to 0.
A third building block 143 can relate to customer types. As can be appreciated, some customers that differ in certain characteristics may be treated the same way by the service process. For example, patients that are characterized as male or female may be processed identically in the service process. Similarly, segments of customers can exist that do not differ in known characteristics, but may still be treated differently by the service process. For example, patients may be prioritized at a certain point in the service process if they previously received a service over other patients that did not previously receive such service. Accordingly, given that service processes can offer different service classes (e.g. priority, routing and service times) to different customer types, the pre-model can be adjusted to model such customer types. Similarly, given that service processes can be the same for different customer types, the pre-model can be adjusted to group pathways for such customers. As can be appreciated, the actual priority rules used by the service process may differ substantially from the ones stated in organizational policies or expected by organizational management. Moreover, such prioritization may depend on other factors such as the occupancy level of the service system, the available process resources at a certain time, etc. Thus, discovering the priority structures that are actually used in the service process can be useful for accurately modelling the service system.

Date recue/date received 2021-10-28 As can be appreciated, different steps can be carried out to fit the third building block 143 and account for different possible service regimens applied to different customer types. In some embodiments, machine learning can be applied to discover the different customer types from the training data 50a. This can be a two-step process. In a first step, machine learning classification and clustering algorithms can be used to identify customer types that are treated differently in one or more parts (for example at one or more different stations) of the service process.
In some embodiments, customer groups can be identified from existing characterization (such as from context data 59) and/or from observed process data, such as a path of the customer through the service process. In a second step, once the different customer types have been identified, such customers can be grouped and the pre-model can be adjusted accordingly. In order to adjust the pre-model, machine learning algorithms can be integrated therein, such as random forests that can predict and generate service times based on generalizations that use the derived customer types. The service time, routing, and inter-arrival time probability distribution functions can then be conditioned on the newly discovered customer types.
A fourth building block 144 can relate to service times. Broadly described, the service time distribution for each service and for each customer type can be zo estimated and applied to the pre-model. In some embodiments, statistical or machine learning methods can be applied to the training data-set 50a, the pre-model and/or the customer types, to predict the duration of a given service for a given customer type. For example, neural network can be used to sample service times for arriving customers. In some embodiments, a plurality of different methods can be used to estimate the service times and generate a plurality of models.
The models can subsequently be tested using out-of-sample data (i.e. using testing data set 50b), and the model that fits the out-of-sample data best can be retained.
A fifth building block 145 can relate to inter-arrival times. Broadly described, inter-arrival time distribution can be estimated for each service and for each customer type. In some embodiments, machine learning methods, for example long short-Date recue/date received 2021-10-28 term memory units in Recurrent Neural Networks, can be applied to the training set 50a to predict arrival time and volume of customers at different services in the service process. This building block can be broken into three steps. In a first step, the arrival process can be modeled using customer, time, and system characteristics (including the derived customer type from the previous building block). A second step can comprise training a predictive model, such as a Recurrent Neural Network that uses these characteristics. In a third step, the predictive model can be used to generate customer arrival times, and prediction intervals can be provided.
A sixth building block 146 can relate to customer routing. As can be appreciated, the routing of customers through the service process may change when the service system is busy or congested. Accordingly, the pre-model can be adjusted to allow modelling state-dependent routing. In an embodiment, routing from each station in the service process to each other station in the service process can be identified for each customer type. As can be appreciated, different methods can be applied to identify customer routing. In some embodiments, machine learning algorithms, for instance k-nearest neighbours classification, can be applied to the training set 50a and the customer types to discover historical paths taken through the process by different classes of customers under different circumstances, for example depending on how busy the process is at a given time. In an embodiment, modelling customer routing can comprise three steps. In a first step, historical routing schemes can be inferred using standard process mining techniques. A
second step can comprise enriching the inferred routing schemes with additional system and customer characteristics (e.g., derived customer type) to better capture customer routing in the model. A third step can comprise generalizing the routes observed in the data (and enriched in the second step) using machine learning methods such as k-nearest neighbors and random forests. This can allow creating appropriate routing rules for the simulation model.
A seventh building block 147 can relate to service discipline. As can be appreciated, each station in the service process can apply different service or Date recue/date received 2021-10-28 queueing disciplines (such as priority, first come first served, last come first served, shortest job first, round robin, etc.) when providing services to a customer.
Accordingly, the pre-model can be adjusted to account for different service disciplines that are used at each station for different customer types. Queue mining algorithms can be applied to the training set 50a to discover the service discipline for services provided at each station in the service system. In some embodiments, a general discipline function can be learned from the training set 50a for each station without specifically identifying the exact queueing discipline that is being used. This can allow learning any service policy, as long as its drivers are recorded in the training data 50a. In some embodiments, if a service at a station is offered by a plurality of servers, the service discipline can specify whether there is a unique queue for all resources waiting to use the service or whether there is one queue for each server. Service disciplines may depend on system and customer characteristics. By default, the pre-model can include a first-come first-served discipline applied to each station. Once a service discipline is identified for the stations, the pre-model can be adjusted by updating each station to use the corresponding identified service discipline.
An eighth building block 148 can be related to capacity. As can be appreciated, each station can have different potential and achievable processing capability that zo can vary at different times and for different customer types. For example, a station can have several resources, possibly of different types, with the composition changing during the day due to shifts. More specifically, in the context of operating an emergency department, the capacity of a service can be different depending on the time of day, accounting for personnel shifts, or depending on the time of year, accounting for personnel vacations. Accordingly, the pre-model can be adjusted to model time-varying capacity and aspects such as shifts and resource variation.
As can be appreciated, different techniques can be applied to identify and/or infer capacity. In some embodiments, capacity level of each service station at each point in time may be available from the context data. In other cases, techniques such as inverse optimization can be applied to the training set 50a to infer the capacity of each of the services as well as daily fluctuations and seasonal variations in the Date recue/date received 2021-10-28 capacity. In some embodiments, inferences are performed to compensate missing data. For example, if no capacity is recorded in the data, state-dependent infinite server queueing models can be used to approximate the demand to capacity ratio.
Such models can use estimates of service times to capture occupancy in the system and its impact on present and future customers.
The building blocks described above can be fitted according to different levels of complexity depending on the data that is available. As can be appreciated, each building block can have different data requirements, and individual building blocks can be fitted only if their data requirements are met. In other words, the sub-step 140b can comprise a preliminary step of determining attributes available in training dataset 50a, identifying one or more building block from among a plurality of buildings blocks whose data requirements are fulfilled by the available attributes, and fitting the one or more identified building blocks. In this fashion, when data is missing, the building blocks can degrade to an aggregated black-box model, i.e.
they can correspond to basic techniques used in queue mining for single-station queues.
The model that results from the model learning step 140 will be referred to hereinafter as a candidate model and can, for example, comprise a queueing network with Markovian routing. In some embodiments, the queueing networks can zo be composed of the following station types: infinite-server queues, a processor sharing single resource queue, a finite-server first-come first-served (FCFS) queue. It is appreciated that other station types are possible in other embodiments, such as queues with priority discipline, reneging, etc. Such station can have context, state and time dependency embedded in their arrival and service processes. As described above, auxiliary attributes from the training dataset 50a can be used to build context and mine the state of the service system, and time dependencies can be created by grouping by time of day and day of the week.
Moreover, machine learning methodology (such as decision trees, random forests and K-means clusters) that uses system occupancy-related features that come Date recue/date received 2021-10-28 from queueing theory, can be used to improve the ability to sample arrivals and service times.
As can be appreciated, a possible benefit of allowing state and time dependencies to be introduced into the model is the ability to circumvent situations when capacity .. data is limited or entirely missing. For example, using infinite server stations, the length of stay can be modelled in a system where the length of stay of each arriving customer depends on the number of customers of similar type in the system, and their current length of stay. This way, correlations that arise in congested systems can be captured indirectly despite the possible lack of explicit capacity data.
Once a candidate model is generated following the model learning step 140, the method 100 can comprise a subsequent step 150 of simulation which can include generating alternative behaviors of the service system using the candidate model via simulation module 11. Since the queueing model defined therein is well-defined, standard approaches for queueing simulation can be applied. As can be appreciated, an advantage of the candidate model is that it can generate data using a combination of simulation and machine learning. For example, as explained above, length-of-stay per station can be modelled in the candidate model as a function of contextual features and state features. This aspect of the model can be based on an ensemble of regression trees, such as random forests.
zo Thus, for every new arrival of a customer, the random forest model can predict the length-of-stay of the arriving customer based on various features (such as age, gender system state, etc.). In some embodiments, noise can be added to such predictions, for example from a noise bucket derived from historical data.
This can allow generating new observations under the assumption that the noise is stationary, and the only elements of the model that depend on the context and state are the means of the length-of-stay distributions.
A final step 160 of the method 100 can comprise performing diagnostics on the candidate model via diagnostics module 13. This can comprise validating the candidate model using in-sample and out-of-sample performance measures, Date recue/date received 2021-10-28 including histograms, confidence intervals, Q-Q plots, hypothesis testing (e.g.
Kolmogorov-Smirnov test for comparing distributions), predictive accuracy measures such as mean squared error, etc. In an embodiment, candidate model can be diagnosed by applying the candidate model to data included in the testing set 50b to make predictions. The predictions of the candidate model can then be compared 170 to the actual historical event data 110. For example, performance metrics can be computed based on differences between the predictions and the actual event data 110. As can be appreciated, if the candidate model meets predetermined thresholds in the performance metrics, the model can be retained and output as a final model 60, for example via output module 15. In some embodiments, for example if one or more performance metrics are below the predetermined threshold, the method 100 can comprise returning to the model learning 140 step to further refine the candidate model. For example, once a model is created, the model can be simulated to generate multiple datasets.
Performance indicators, such as the length of stay of customers in the system, can be calculated.
If the distribution of these performance indicators does not match the originating data, it can be conclude that the model is biased and the model can be re-fitted using a different set of features or by replacing one of the building blocks.
One example of such replacement could be using a different machine learning zo algorithm that models service times or engineering additional features to be used in the algorithm. Cross-validation can be used to tune the hyperparameters of the various building blocks. The resulting model 60 can be accurate in both in-and out-of-sample, providing both descriptive and predictive power for analysis purposes.
As can be appreciated, the model 60 can be used to help make predictions about the effects of different interventions on the service process. An intervention can correspond to a modification of the service process or of the conditions under which the service process is executed that can have the potential of impacting the performance of the service process. Examples of interventions include speeding up or slowing down services, changing the routing between services for certain customer types, changing the capacity of services, changing the service discipline Date recue/date received 2021-10-28 of services, or changing the resource types, among others. As a more specific example, if the process to be analyzed corresponds to the operating of an emergency department in a hospital, an administrator may want to know the effect of running the emergency department with a different number of doctors at a specific time of day, or the effect of changing routing and priority policies, or the effect of a greater proportion of patients necessitating a consult.
With reference to Figure 5, an exemplary method 500 for predicting impacts of interventions on a service process is shown according to an embodiment. As can be appreciated, the method 500 can be carried out using the model 60 and/or historical data 50 as an input. Using these inputs, the method can allow estimating impact of specified interventions based on historical data and/or can allow estimating impact based on designed experiments to evaluate "what-if' questions.
In some embodiments, the method 500 can allow automatically proposing interventions, and the impact of such proposed interventions can be evaluated.
A first step 510 of the method 500 can comprise intervention specification in which the interventions to evaluate are defined. In some embodiments, the interventions can be user-specified. For example, a user can specify affected model blocks in a user-friendly intervention language, by specifying where one or more interventions could be applied (arrivals, resource types, and service times) and for which they would like to run a "what-if' analysis. In some embodiments, possible interventions can be identified from the building blocks 141 to 148 and can be suggested to the user, who can subsequently select from among the suggestions. In some embodiments, interventions can be proposed for external constraints. As can be appreciated, careful consideration can be given to interventions that are related to external constraints. Inducing external partners to change their processes in order to relax constraints on the studied service system may require analysis that captures the impact of these external constraints on the studied service system.
Accordingly, a discussion with external partners can be useful only once this impact is quantifiable.
Date recue/date received 2021-10-28 A second step 520 can comprise intervention detection, where 'natural' occurrences of user-specified intervention conditions can be detected in historical data. More specifically, the event data 110 can be analyzed to identify historical times periods where conditions corresponding to the user-specified intervention existed in the historical event data 110. For example, if an intervention corresponds to an increase in the arrival rate for a certain type of resources, there may have been historical periods where such increased arrival rates were observed in the event data 110. If a historical occurrence can be identified, statistical comparison of the system performance under these conditions and of the system under baseline (i.e. as-is) conditions can be performed, and these comparisons can be output as diagnostics 70. As can be appreciated, periods identified in this manner can be treated as "natural experiments" and can allow making predictions about the likely result of the intervention with a high level of certainty.
As can be appreciated, it is possible that no historical occurrences can be identified in event data 110 for a specified intervention and/or for a specified combination of interventions. In such cases, a subsequent step 530 can comprise a simulation-driven analysis in which the model 60 is used to infer the impact of different possible interventions such that diagnostics 70 can be produced therefrom. In this fashion, a simulation-driven analysis of the intervention impact can be provided as zo apposed to a data-driven analysis.
In an embodiment, the simulation-driven analysis 530 can comprise a first sub-step 530a of scenario selection. As part of this sub-step, one or more interventions (referred to as scenarios) can be selected for use as part of the simulation.
In an embodiment, the scenarios can be user-specified. An intervention-aware simulation model can subsequently be constructed to allow simulating the joint impact of the selected interventions. Returning to the example of an emergency department, if a user only selected a staffing intervention for doctors, and evidence for having varying values for the number of doctors is found in the event data, this information can be integrated into the simulation model such that a what-if analysis can be executed. The user can observe a range of possible values with (or without) Date recue/date received 2021-10-28 confidence intervals. This can allow illustrating the impact of changing the values of staffing on various performance measures.
A second sub-step 540b can comprise a causality study. In this subs-step, the simulation model can be used to project the service system performance from the observed level of interventions to performance under different levels of interventions. In other words, a data-driven simulation model, such as the model 60, is used as a causal model to test the impact of different interventions.
As can be appreciated, when the simulation executes, confidence intervals for the scenarios that were not observed in the event data 50 can be provided. The resulting diagnostics 70 can be observed and the simulation model can be changed again until the user can examine all interventions of interests, along with these respective impacts.
In some embodiments, it may not be possible to infer impact of certain interventions based on the existing data. In such cases, the method can comprise providing recommendations on the collection of missing data. The method can further comprise providing suggestions for short term changes that can help with the collection of additional relevant data. Such data can enable steps for data-based comparisons identified in the previous steps.
As can be appreciated, by producing diagnostics 70 relating to different possible zo interventions, trade-offs between costs and benefits can be evaluated in order to identify optimal levels of interventions within user-specified constraints, and given costs assigned to each of the intervention parameters. With reference to Figure 6, an exemplary method 600 for optimizing intervention in a service process is shown according to an embodiment. The method 600 can receive three inputs: event data 50; model 60, including feasible interventions identified according to method 500;
and a set of use-specified costs 80.
A first step 610 of the method 600 can comprise cost assignment, where the user can input different costs 80 that are matched against the building blocks in the model 60. A second step 620 can comprise visualization, in which performance Date recue/date received 2021-10-28 measures are used to display the benefit of different interventions, including confidence intervals. This can be done by visualizing trade-off curves of different interventions and their economic and statistical significance impact of performance measures. A final step 630 can comprise optimization in which interventions that would aim at optimizing with respect to the pre-defined costs and objectives can be found, and corresponding prescriptions 90 can be made.
The methods and systems described above can allow for automated data-driven modeling, analysis, and optimization of service processes that are common in service systems and often modeled as complex queueing networks. The described systems and methods can mine event logs generated by information systems to discover process structure and construct predictive models for their operational characteristics. Subsequently, two types of models (structural and predictive) can be used to simulate and forecast future behavior of the process under a variety of conditions and interventions, as well as to identify optimal operational parameters.
In the described embodiments, the systems and methods apply techniques that combine study fields such as queueing theory, statistics, machine learning, and process mining. Specifically, the described embodiments utilize queue mining, which is a field that studies the combination of the above with an emphasis on the discovery of useful queueing networks from data, and on the application of these zo models to enrich machine learning models for prediction and sampling.
Although particular examples have been provided (i.e. in the context of an emergency department), it will be appreciated that the described systems and methods can be applied to a wide variety of other service systems such as healthcare (long term care homes), cloud computing (data services), and supply-chain management systems, among others. Given that a focus is on modeling processes in which queues are prevalent, applications are also possible for use in manufacturing.
Although particular advantages and applications of the invention have been explicitly described herein, other advantages and applications may become Date recue/date received 2021-10-28 apparent to a person skilled in the art when reading the present disclosure.
The invention is not limited to the embodiments and applications described, and one skilled in the art will understand that numerous modifications can be made without departing from the scope of the invention.

Date recue/date received 2021-10-28

Claims (28)

1. A method for automatically generating a model of a service process, comprising:
- receiving historical event data corresponding to activities processed by a service system, said historical event data comprising a plurality of events and, for each event, values corresponding to a plurality of attributes, said plurality of attributes including at least a participant identifier, an activity identifier and a timestamp;
- processing the historical event data to extract system occupancy information and enhancing the historical event data by adding the system occupancy information as at least one additional context attribute;
- separating the enhanced historical event data into a training dataset and a testing dataset;
- building a queueing network model by extracting activities and estimating pathways and routing probabilities from the training dataset; and - enhancing the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways.

2. The method according to claim 1, comprising preprocessing the historical event data prior to extracting system occupancy information, wherein preprocessing the historical event data comprises at least one of:
- identifying in the historical event data at least one event with a missing value for at least one attribute and either prompting a user to input the missing value or removing the at least one event from the historical event data;
- identifying in the historical event data at least some values provided in a first format, and encoding the at least some values into a second format that is different than the first format, said second format being adapted for being exploited via machine learning;
- identifying in the historical event data a subset of the activities that occur with a frequency below a predefined threshold and removing from the historical event data events that correspond to the subset of the activities;
and - identifying in the historical event data at least one pair of activities that directly follow one another for participants, and adding to the historical event data a temporal relationship between the first activity and the second activity.

3. The method according to claim 1 or 2, wherein the occupancy information comprises an indication of at least one of congestion, trend and seasonality in the service process.

4. The method according to any one of claims 1 to 3, wherein processing the historical event data comprises calculating correlations between sojourn times of participants in the service system during overlapping periods and adding the calculated correlation as an additional context attribute.

5. The method according to any one of claims 1 to 4, wherein processing the historical event data comprises, if the participants are not-pre-assigned to groups, grouping participants in the service system by similarities in length-of-stay and adding a number of participants in each group over time as an additional context attribute.

6. The method according to any one of claims 1 to 5, wherein enhancing the queueing network model comprises using queue mining to fit a plurality of queueing building blocks from the training dataset.

7. The method according to claim 6, further comprising determining attributes available in training dataset, identifying one or more queueing building block from among the plurality of queueing buildings blocks whose data requirements are fulfilled by the available attributes, and fitting the one or more identified queueing building blocks.

8. The method according to claim 6 or 7, wherein the plurality of queueing building blocks comprises at least one building block configured to discover and group customer types through machine learning.

9. The method according to claim 8, wherein the plurality of queueing building blocks comprises at least one building block configured to predict durations of activities for different customer types using machine learning.

10. The method according to claim 9, wherein the at least one building block configured to predict durations is configured to use a machine learning model to sample service times for participants arriving at activities in the service process, said machine learning model being trained on enhanced historical event data comprising context attributes including a service time distribution for each activity and for each customer type.

11. The method according to any one of claims 8 to 10, wherein the plurality of queueing building blocks comprise at least one building block configured to predict arrival times for different customer types using machine learning.

12. The method according to claim 11, wherein the at least one building block configured to predict arrival times comprises a machine learning model to predict arrival times of participants to different activities in the service process, said machine learning model being trained on enhanced historical data comprising context attributes including arrival time distributions for each activity and for each customer type.

13. The method of any one of claims 8 to 12, wherein the plurality of queueing building blocks comprises at least one building block configured to model routing rules for a given customer type using machine learning.

14. The method according to claim 13, wherein fitting the at least one building block configured to model routing rules comprises: inferring historical routing schemes using process mining; enriching the inferred routing scheme with the customer type; and generalizing the routes using machine learning.

15. The method of any one of claims 8 to 14, wherein the plurality of queueing building blocks comprises at least one building block configured to model different service disciplines applied at different activities for different customer types.

16. The method of any one of claims 6 to 15, wherein the plurality of queueing building blocks comprises at least one building block configured to model external constraints that introduce delays in the activities in the service process.

17. The method of any one of claims 6 to 16, wherein the plurality of queueing building blocks comprises at least one building block configured to discover a queueing network structure describing the service process.

18. The method according to claim 17, wherein fitting the at least one building block configured to discover the queueing network structure comprises identifying activities in the historical event data that occur with a frequency above a predetermined threshold, and integrating the identified activities in a network of queues.

19. The method of any one of claims 6 to 18, wherein the plurality of queueing building blocks comprises at least one building block configured to model time-varying capacity of different activities in the service process.

20. The method according to any one of claims 6 to 19, further comprising simulating the service process by applying the testing dataset to the enhanced queueing network model to generate predictions therefrom.

21. The method according to claim 20, further comprising identifying differences in predictions made by the enhanced queueing network model and actual historical event data, and calculating performance metrics to quantify said differences.

22. The method according to claim 21, further comprising refining the enhanced queueing network model if the calculated performance metrics are below a predetermined threshold.

23. The method according to claim 22, wherein refining the enhanced queueing network model comprises at least one of: tuning hyperparameters of machine learning algorithms to re-fit at least some of the plurality of queueing building blocks, applying different machine learning algorithms to re-fit at least some of the plurality of queueing building blocks, and re-fitting the enhanced queueing network model by fitting only a subset of the plurality of building blocks.

24. The method according to claims 22 or 23, wherein the enhanced queueing network model is refined iteratively by repeating steps of adjusting at least some parameters of the enhanced queueing network model and simulating the adjusted model until calculated performance metrics are above the predetermined threshold.

25. The method according to any one of claims 1 to 24, further comprising evaluating an impact of process interventions by: specifying interventions;
determining whether the historical event data contains events that correspond to the interventions; responsive to determining that the historical event data contains events that correspond to the interventions, extracting an impact of the interventions from the historical event data; responsive to determining that the historical event data does not contain events that correspond to the interventions, simulating the service process with the interventions using the enhanced queueing model to predict an impact of the interventions; and suggesting additional process data that needs to be collected to evaluate an impact of the interventions.

26. The method according to claim 25, further comprising deriving prescriptions by: determining possible interventions; specifying a cost function for the possible interventions; specifying a performance function for the service process;
simulating the service process with at least one of the possible interventions using the enhanced queueing model to predict an impact of the at least one of the possible interventions; and determining that a subset of the possible interventions optimizes a ratio of the performance function and the cost function.

27. A system for automatically generating a model of a service process, comprising:
- an input module configured to receive historical event data corresponding to activities processed by a service system, said historical event data comprising a plurality of event and, for each event, values corresponding to a plurality of attributes, said plurality of attributes including at least a participant identifier, an activity identifier and a timestamp;
- a data enhancement module configured to process the historical event data to extract system occupancy information and enhance the historical event data by adding the system occupancy information as at least one additional context attribute; and - a model learning module configured to separate the enhanced historical event data into a training dataset and a testing dataset, the model learning module comprising a process discovery submodule configured to build a queueing network model by extracting activities and estimating pathways and routing probabilities from the training dataset, and a queue mining submodule configured to enhance the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways.

28. A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processor of a computing system, cause the computing system to:
- receive historical event data corresponding to activities processed by a service system, said historical event data comprising a plurality of events and, for each event, values corresponding to a plurality of attributes, said plurality of attributes including at least a participant identifier, an activity identifier and a timestamp;
- process the historical event data to extract system occupancy information and enhance the historical event data by adding the system occupancy information as at least one additional context attribute;
- separate the enhanced historical event data into a training dataset and a testing dataset;
- build a queueing network model by extracting activities and estimating pathways and routing probabilities from the training dataset; and -enhance the queueing network model by processing the training dataset to group or remove at least some of the pathways and estimate durations of activities in said pathways.