A process is a list of different steps linked together by a logic flow. In fact, if we think a bit deeper about that, we’re surrounded by processes. Every time everything we do can be most of the time divided into multiple sub-tasks. When you go to bed, what do you do ? first of all you brush your teeth, after that you undress, and wear your night suits, then you finally go to bed. Somehow the Process “go to bed” is a global sequence of these different actions you’re doing every day.
Of course, a process can be more complex and for example you can have in these various sequences of actions many decisions (based on the previous actions or other criterias), some repetitive tasks and also several back and forwards (loops). Moreover you also have to take in account some tasks are not done only by yourself and must be performed by other people or groups. It’s also important to add the time dimension as some of these tasks may have to be executed in a certain duration !
Below this is a simple view of an Order To Cash Process Process (OTC):
So, what we should consider when we talk about a Process:
- A process is a set of different actions/tasks and conditions performed in a specific order. We can easily draw such a process by using a flowchart.
- A process and its sub-tasks can have a time dimension.
- Each Process Steps or flow task can be affected to a specific resources (people, group, service)
- A Process Step inside a process is independent in the way it has its own inputs and its own outputs. These IN/OUT variables can be shared in the flow to make decisions for example. However the same Process Step can appear several times in the same Process Flow (and with differents inputs/outputs)
To describe a process flow we then need these minimum assets:
- The Process Steps
- [MANDATORY] The Process Step name which describes in some short words (or a code) the action
- [OPTIONAL] We can also have some Process Steps attributes (like the responsible for the task, a cost, and any other informations which provides some insight about the task itself)
- How to link these steps together (their relationships)
- [MANDATORY] Each relationship is defined between two Process Steps. Or course the same Process Step can have many relationships with other Process Steps (and also itself !)
- [OPTIONAL] Relationships attributes
This informations can be provided by the data itself of course and also by an algorithm which will describe how the Process Flow is performed. But before going further, let’s take a look at the step interactions and how we can rely on them together to build (by using an algorithm) this flow.
To rebuild the Process Flow (based on the data) we can use several strategy:
- Tree description: We can use the relationship in the data itself (for example if it exists two fields per Process Step activity: one for the Process Step and antoher one for its father in the hierarchy). Unfortunately, this situation is quite rare.
- Timeline description: We can recreate the Process Flow by using the timeline of this sequence of activities. In this case we must have (as data) the Process Step of course, but also when this process Step is really occuring in the flow. This strategy is more common as most of the time it’s easier to have Process data with this shape.
These techniques and algolithms ar the basis of the all Process Mining solutions and we could list some of the most famous:
- Alpha Algorithm or Alpha Miner
- Heuristic Miner (introduced in 2001)
- Inductive Miner
But before going futher in the way we will rebuild the Process Flow we may have to look at each step more important: how can be bound theses ones at any stage of the process flow ? That would mean the first step can directly lead to the last and not coming back. Of course sometimes that may not make any business sense, but that would be considered as possible !
Secondly the relation between two steps in a process flow can be:
- Causal: The second step is directly linked to the first one in this order (and not the opposite). Of course the direction of the arrow between the steps (the relation itself) is fundamental
- Parallel: Several steps can occur in parallel after executing a specific step
- Loop Back: a step can loop back on itself
Having a start and an end of the flow is normally something mandatory when we design a process flow, however we’ll see later, when analyzing a process it’s not sometimes not so obvious to find out these two extremities of the process. So from an analysis perspective, we may consider having the starting and ending steps not mandatory.