Process analysis

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. Soon realized that we are in trouble, 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
  • check 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 was also necessary, so we have visited the affected unit in the plant (or the warehouse) and watched people while they were working. In some cases it happened 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?). 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 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 uses the documented ones (so we replayed what we had). 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.

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 achieve 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 learnt in practice 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *