We use leading edge techniques and tools that enable us to visualize and analyze the processes. So in the end you have a clear and fact based picture of your processes and this information enables you to decide how to improve and optimise your operation.
This is where you start making money. The new insight allows you to pin-point bottlenecks, loops, unwanted process-steps, etcetera and together with your process owners and lean experts we work to eliminate these inefficiencies. The process miners follow the process and can immediately see the effect of the measures taken.
A little more background
Process mining starts with applications that support the business processes. Conditional is that these applications log event information in logfiles. The logfiles (data sources) that can be used for Process Mining are spreadsheets, databases, transaction logs, audit trails, etc. Most applications for administrative tasks, automated processes, workflow systems or support systems log process data in audit trails or in transaction logs. We use these logfiles to discover the associated process and construct the models that describe and visualize the process flows. Standard formats for the data that will be used for the mining process are MXML (Mining eXtensible Markup Language) and XES (eXtensible Event Stream). XES was selected by the IEEE Task Force on Process Mining as the standard format for logging events. But also event data CSV (Comma-Separated Values) or XLS (Microsoft Excel) formats can be used to mine.
Smart software runs smart algorithms against the logfiles, and are able to derive the process models from the logged data (and needless to say that only process steps that are logged will be discovered). Now we scrub the data, build the process model and start with the analysis.
We can look for anomalities, loops, bypasses, bottlenecks, examine cases, create views, build filters and run the statistics. It is also possible to use process mining to monitor deviations (e.g., comparing the observed events with predefined models or business rules in the context of SOX).
Data Requirements
The event log we need for process mining has a few simple characteristics. There is a one-to-one relationship between the so-called caseID (the event we try to follow through the process), the activity (process-step) that was performed and a time-stamp.. So, when we follow a request (the case-ID) through an administrative system, the first step (the activity): “request submitted” and the associated time-stamp must be in one line in the event log.
From the data sample above (from Fluxicon) you can see why even doing simple process-related analyses, such as measuring the frequency of process flow variants, or the time between activities, is impossible using standard tools such Excel. Process instances are scattered over multiple rows in a spreadsheet (not necessarily sorted!) and can only be linked by adopting a process-oriented meta model.
Additional columns can be included for the analysis if available. For example, in the data sample there are further attributes that categorize the service request: A case was opened by phone, resolved by an external specialist, and the urgency was categorized as level 2. We might also include the resource or department that performed an activity. But the mandatory columns are just the three requirements above.
