As mention in the previous section, the process in question is part of a petro- chemical organisation’s maintenance procedure. The process forms part of the organisation’s asset management implementation where the information sys- tem is able to schedule and manage the work and state changes within the process. From here on, state changes will refer to the completion of one task in the process and the progression to the next. The control-flow perspective of the process can be seen in Figure 4.1 with the preferred path being highlighted in red.
From the case study briefing, it was clear that while the process had a planned route, there was no feedback on what was happening in the real word concern- ing the actual paths. The planned process shown in Figure 4.1 is also outdated in that the actual process includes more tasks than are shown here. This is as a result of the changing environment in which the process operates and how the organisation updates the process to improve operation. A full list of all the activities and their descriptions are available in Appendix A, Table A.1.
Approved and In Progress (“IP”) Work on Site Completed (“WSC”) Completed Costing (“CC”) Completed Costing Approved (“CCA”) Reject Contractor Costing (“RCC”) Completed and Invoice Checked (“INC”) Approved Work in Question (“ATW”) Approved within Region (“AR”) Approved within Conformation (“AC”)
Closed and Sent for Review (“CSM”)
Closed and SAP Extraction Generated (“CSG”) Reject Call Centre
Process (“RCP”)
Closed (“CL”) Start
End
Figure 4.1: Base Maintenance Process (Planned Process).
Because of a non-disclosure agreement, more details regarding the process cannot be unveiled. The case study will thus be missing some much desired detailed analysis. This will also be reflected in the results discussion as specific actions towards process improvement cannot be described, only with regards to the activity descriptions in Table A.1.
4.3
Data Collection
Data collection was done by utilising the organisation’s Enterprise Asset Man- agement System (EAMS). Implementation of the EAMS is managed by a PAM service provider who conducts the data analytics with regards to captured as-
set information. The EAMS has the ability to facilitate an asset register, record the conditions of assets within this register and manage work orders related to the maintenance of physical assets. As work orders captured in this system are subject to the processes which support the physical assets within the organisation, they can be used to reconstruct the supporting PAM pro- cesses. It is thus these supporting processes which enable the value creation of the physical assets. As the process can now placed within the PAM strategy of the organisation where value creation occurs, the conditions discussed in Subsection 2.1.2 are met.
Data extraction from the system was done by the technical team leader where he was able to retrieve transactional data via SQL database queries. The EAMS system does not refer to these records as an event log as discussed in this thesis but rather refers to it as a “change log”. This entails that every state change of the monitored process is recorded. The fields retrieved for the change log are:
• CaseID; • Resource; • Timestamp;
• Transition From; and • Transition To.
As can be seen, the structure is closely related to the ideal case described in Subsection 3.3.2.2. The only difference results from the change log interpre- tation of the system where status changes are recorded at certain times when the process progresses from one status to another. States referred to here can be interpreted as the progression of tasks or activities within the process. The only issue with this is that there are no separate entries for the start and end of the process states. The EAMS records one entry which describes the tran- sition from one state to the next.
The data is exported to a csv (comma-seperated text-file) which enables uni- versal usage. While it could not be exported to the desired mxml format, it
does grant the analyst the ability to open the log with a variety of other ap- plications. The log was reformatted to mxml by the ProM Import Framework software package 1. The data set contains records from the 4th of January
2014, 5:59 AM to the 8th of June 2015, 11:35 AM. 33,614 records are con- tained within the data set, which in terms of this case study refers to the number of status changes. A preview of the data is shown in Table 4.1.
Table 4.1: Event log preview
CaseID Resource TimeStamp TransitionFrom TransitionTo
AH10441# – 29/4/2015 13:30 CL RWO
AH10441# – 29/4/2015 13:31 RWO WSC
AH10441# – 29/4/2015 13:33 WSC CC
AH10441# – 29/4/2015 14:00 CC CCA
AH10441# – 30/4/2015 8:27 CCA INC
AH10441# – 7/5/2015 14:37 INC ATW
AH10441# – 7/5/2015 14:38 ATW AR AH10441# – 7/5/2015 14:38 AR AC AH10441# – 10/5/2015 3:00 AC CSM AH10716# – 15/1/2015 11:27 CL RWO AH10716# – 15/1/2015 11:28 RWO WSC AH10716# – 15/1/2015 11:33 WSC CC AH10716# – 15/1/2015 12:01 CC CCA
AH10716# – 15/1/2015 12:16 CCA INC
AH10716# – 16/1/2015 4:51 INC ATW
AH10716# – 16/1/2015 13:10 ATW AR
AH10716# – 16/1/2015 13:11 AR AC
AH10716# – 18/1/2015 3:00 AC CSM
AH10716# – 21/1/2015 9:59 CSM CSG
While utilising manual exploration of the data in Microsoft Excel, some irrel- evant data points were observed. The first stage of filtering was simply done by removing all cases that contained only one entry as this does not convey a process and is very likely to be the result of the system or human input error. It was also seen that some cases were opened by the system only to be closed immediately after. As this will also only interfere with the created model and skew results, all cases with only two entries were also removed. A discussion with the data analyst revealed that there was a change in the process model
and the activities within the process from 2014 to 2015. This leads to the discarding of all data for 2014. Even though only 6 months worth of data remained, it still included 198,642 records which are adequate to perform the desired analysis.
4.3.1
Data Transformation
As data is almost never in the exact form preferred for processing, some al- teration to the event log had to be made. The first of these alterations was done because of the way the EAMS captures state changes as discussed in the previous subsection. An algorithm was written in R 2, an analytical program-
ming software package, to insert an extra line before every process instance. This extra line copied the “TransitionFrom” field to the “TransitionTo” field. The “TimeStamp” for this entry was simply taken as one minute before the next line to ensure that the event will be placed first during processing. An example is show in Table 4.2.
Table 4.2: Event log row addition example.
CaseID Resource TimeStamp TransitionFrom TransitionTo
AH10441# 29/4/2015 13:29 CL
AH10441# ChantaldeS 29/4/2015 13:30 CL RWO
The second alteration was done with respect to the anonymisation of the data. The event log contains a “resource” field which indicates the person responsible for logging the state change. As part of the agreement with the organisation who supplied the data, this field was anonymised. To do this, the Anonymize Log ProM plug-in was used. This plug-in replaced all entries in the resource field with a respective letter.