Use case: Road traffic fine management

Use case walk-through

Dataset description

The  event log of a “Road traffic fine management” process  (managing fines punishing road traffic infractions, i.e., speeding) contains real data of an Italian regional agency for traffic management. 

According to domain experts, the process normally operates as follows: 

  • A fine is created (Create Fine). 
  • The fine is sent to the offender’s place of residence (Send Fine).
  • When the offender receives the fine, the date of reception of such notification is also registered (Insert Fine Notification).
  • The offender has 60 days to either pay the fine (Payment) or appeal against it. After this period, a penalty is added to the fine amount (Add Penalty). 
  • If an appeal is initiated within 60 days, it is sent to the corresponding prefecture (Send Appeal to Prefecture), and registered when it is received (Insert Date Appeal to Prefecture).  The results of the appeal are sent back to the municipality (Receive Result Appeal from Prefecture) and notified to the offender (Notify Result Appeal to Offender), which can appeal against the result (Appeal to Judge). If the offender does not pay (possibly after a denied appeal), the case is sent to an external credit collection agency that will contact the offender to collect the payment (Send for Credit Collection). The part of the process after the fine is sent out for credit collection is not captured in the event log. 
  • Exception: parking tickets can be paid  immediately, after the ticket creation (in which case the paperwork is bypassed and unnecessary administration costs are avoided).


The stories in a snapshot 

  • What are the journeys of an offender through the bureaucracy of the road traffic  management system? 
  • What stands out in terms of waiting times? What could be considered atypical behaviour?
  • What stands out in terms of repetitive behaviour? 

Dig into the stories

  • What is typical behavior for each category of interest?
  • Any particular behavioral difference (in time / successions of steps) between offenders who (eventually) pay their fines and those who don’t? 

Optimization checkpoints 

  • What is the story behind unwanted performance indicator values (e.g. outstandingly long end-to-end waiting times | loops | successions of steps)? Is there anything that could be done to decrease them? 
  • Are there unnecessary repetitive steps that contribute to increasing delays in the system? 

Dataset preprocessing

The dataset includes 150370 cases.  After removing the columns recording NaN on more than two thirds of the values, the dataset retained the following: 

  • Must-have configuration information for a process mining analysis
    • ‘Case’ – the id of the fine 
    • ‘Event’ – the status of the fine, one of 11 distinct values (‘Create Fine’, ‘Send Fine’, ‘Insert Fine Notification’,   ‘Add penalty’, ‘Send for Credit Collection’, ‘Payment’,  ‘Insert Date Appeal to Prefecture’, ‘Send Appeal to Prefecture’,  ‘Receive Result Appeal from Prefecture’, ‘Notify Result Appeal to Offender’, ‘Appeal to Judge’)
    • ‘startTime’, ‘completeTime’ – the timestamp associated with the event
  • Columns that may be used for filtering purposes:  ‘Amount’, ‘article’, ‘points’,  ‘org:resource’, ‘vehicleClass’, ‘totalPaymentAmount’,  ‘notificationType’, ‘expense’, ‘lastSent’. The usefulness of slicing the dataset based on information provided in the last three columns ( ‘notificationType’, ‘expense’, ‘lastSent) is debatable, as they include many null values. 



7.3% of the cases represent unusual cases (based on very small  group sizes, e.g. of 1-80), and are not indicative of overall systemic behaviour. While interesting , they are irrelevant for the purpose of understanding a birdview of the flow, and for global optimization purposes. They were ignored in the analysis stage. 

13.6% of all cases are represented by incomplete “Create Fine → Send Fine” journeys (i.e. which start, but do not conclude within the total time frame of the data). They were simply left out in the analysis stage. 

Process discovery

Let’s uncover the actual behaviour of the people when it comes to receiving and (not) paying a fine.

Desired behaviour

39.2 % of the journeys are represented by desired behaviour (Payment observed). 

  • 30.6% of the cases (the second most frequent pathway)  represent tickets paid on the spot: Create Fine →  Payment .
  • In 6% of the cases, offenders pay the fine after receiving an additional penalty, and the story ends with this Payment. 
  • In 2.1 % of the journeys, the ticket is created and sent to the place of residence of the offender, and a Payment is made eventually (an average end-to-end waiting time of ~ 4 months )

Atypical behaviour in this category includes: 

  • Payment observed as repetitive behaviour 
  • Payment observed, but (surprisingly) followed by added penalties / action initiated by the external credit collector agency (which probably should have been notified to not trigger an unnecessary bureaucratic chain). It might be that this shows a possible lack of synchronization between the accounting department and the external credit collection agency (which was not announced in time that the case was resolved once a Payment was made) 

Undesired behaviour

39.9% of the journeys represent undesired behaviour (no Payment observed at any point in the path). 

  • 37.6% of all journeys ( the largest group of all journeys) impose an  average end-to-end waiting time of 16553 hours, i.e. approx. ~2 years. These are people who officially receive the fine along with penalties for not paying it in time, and eventually end up being addressed by the external collection agency. 

Atypical behaviour in this category includes: 

  • a penalty is still added officially despite the unexpected initiation of an appeal by the offender (1.7% of all cases).  
  • 0.3 % of all journeys describe a pattern of behaviour where people simply choose to initiate an appeal only after they officially get an additional penalty for not addressing the fine in the first place. 

Process conformance: when reality does not match expectations

When the unexpected happens (log-moves, yellow)

Steps that are not expected to happen, but do, are shown in yellow. 

  • Surprisingly, a  Payment is executed (at least) twice in more than one journey. Possible reasons include: 
    • a possibility to pay in terms.
    • a sudden eagerness to pay the original fine at the same time as a penalty was added for the delay (or, in cases with extreme delay of almost 2 years, at the same time as an official action was initiated from the credit collector agency) resulting in the need for a second transaction to pay the extra amount 
  • A possible lack of synchronization between the departments / officials in charge with the various steps of the fine management process is again observable from the log-only activities.  For instance, in 1.7% of the cases, a penalty is officially added despite an appeal being initiated and registered. In 0.2% of the cases, a fine is (surprisingly) still officially sent to the residence of the offender, after a payment is made (a procedural error that could lead to loads of unnecessary paperwork). 

When the expected does not happen (model moves, mauve)

Steps that are expected to happen, but don’t, are shown in mauve. 

  • In a few cases there is an expectation that a Fine is sent again to the offender’s home, once an appeal is concluded and a result appeal is notified. This does not happen in practice. Further analysis would be needed by an in-house from the Italian local municipality, who would know whether this is desirable behaviour or not, in the long term. 

Optimization checkpoints 

  • What is the story behind unwanted performance indicator values (e.g. outstandingly long end-to-end waiting times | loops | successions of steps)? Is there anything that could be done to decrease them? 
    • Almost 40% of the fines received do not get resolved in the timeframe considered for analysis, and end up being taken over by the external credit collector agency. One solution would be to officially decrease the unnecessarily long waiting time (of  approx. 2 years) before transferring an issue to a third party. 
    • Unwanted successions of steps uncovered revealed a possible lack of synchronization between the sub-departments in charge with accounting / all other paperwork. One solution would be digital transformation:  to ensure that once payments are made, updates are automatically sent  to the other subsystems.
  • Are there unnecessary repetitive steps that contribute to increasing delays in the system? 
    • Payment is unexpectedly executed twice in 2.5% of the cases, most probably because people omit to pay the penalty received the first time. This issue could be easily tackled by not allowing payments that do not match the total amount of the fine, and displaying a message to inform on the spot about the reason for payment denial.