Process analysis

Back in 2005 I was hired as a trainee to take part in assessment of in-built checkpoints in several massive processes of a big manufacturing company to show they are SOX compliant. It was a very interesting internal control project (that’s how it was called). We received the best practices from the project office and we had to compare if our subsidiary is implementing at least the same level of checks if not more rigorous ones. These best practices were in form of presentations and questionnaires which we had to fill out. We thought it is a very easy task. We went straight to colleagues who were performing these checks on a daily basis as part of their job and asked them if they do these checks or not. We soon realized that this is a much bigger challenge, because

  • question sometimes was not clear or was ambiguous
  • in some cases it turned out the person who answered was not the same as who performed the check
  • some checks did not exist at the expected place in the process, because the process was completely different

First of all we went through all questions we had issues with and clarified them with the program manager. To deal with the above issues we had to

  • identify and resolve ambiguity
  • cross check each and every answer
  • explore and document all the relevant processes

Contradicting answers were very common, so rather than just sending over the questions with some more description we conducted in-depth interviews where we could explain questions and see body language as well. Sometimes observation of the actual process in practice was also necessary. This means we have had to visit the affected unit in the plant (or the warehouse) and we were watching people while they were working. In some cases we had to repeat it multiple times, some of these were randomly timed or selected based on specific conditions. For example: do they perform checks on a rainy day as well? do they measure small trucks as well or just big ones?

Wherever it was possible we reconciled answers received with documentations (both paper based and electronic). We paid high attention to sudden changes in figures, so we compared our results with data from the previous and next few days. So if they have worked extremely slowly, just because we were there, we went back to check if it was an exception or they were performing a show for us. I think the biggest value we generated were the process flow charts with detailed descriptions.

We used all information we gathered from internal policies, complemented with interview results and our observations, then verified by the interviewees. Finally we validated these diagrams against real cases to check it. This way we were able to justify some deviations from the best practice (where the entire process were different, not just a checkpoint was missing) and identify those which had to be corrected. That’s how I learnt process analysis in practice.

Fast forward to November 2014.

A week ago I started to learn about process mining, which I could have used before when I worked on projects where we had event logs. Process mining is a technique which can be used to discover the real processes merely based on event logs of workflow systems. It also can be used for conformance checking and to improve our existing processes. I think if I were aware of its existence we could have achieved even more back then in the internal control project. I really enjoy the course (it is in progress) so far and very excited about the forthcoming practical sessions when we will learn how to build business process models using raw event data.

After I finish the course all I will need is a project to apply what I have learnt in practice 🙂