When it comes to processes, most of the training and documentation target the format and content. However, I would like to offer the perspective of how to tackle the process creation, validation, and follow-up in this article.
Why do you need to analyze and model processes?
Well designed and documented processes have a great deal of benefits. They can help scale up, increase efficiency, remove uncertainty, improve business continuity, etc.
By simply analyzing them, you can:
- identify redundancy,
- increase clarity,
- remove bottlenecks,
- improve standardization,
- prepare process automation
Here’s a structured approach to make sure that a process analyst and business analyst can model processes of any given organization.
What is not covered by the article
Before getting into the subject matter, I would like to specify the scope of the article. For the sake of length, some topics won’t be covered:
- Process improvement (KPIs, Six Sigma, DMAIC, etc.): It is another discipline altogether! In our case, we will we focus on analyzing, modeling, and validating our process. Though, process improvement is a perfect next step!
- Root cause analysis (Pareto, Failure mode, Fishbone diagram, etc.): like the previous points, there are many methodologies (and training) on that topic, yet none of them are discussed in this article.
- BPMN: I will not discuss the “language” used to format the process
- How to present them to management: This is a step after validation of the process model and a different topic.
Step-by-step approach for process modeling:
Step 1: Preparation
Your main objective for this step: know what you will have at the end?
1 – Identify stakeholders
This step could take some time at first, depending on the involvement of the project sponsor. Even though it is the first step, the list should be updated, as unexpected stakeholders could be identified along the process. Depending on the number of stakeholders, a structured tool such as a power/influence grid helps focusing on the right people. In case of doubt about a person’s influence, put it at the highest influence and lowest interest.
2 – Contact stakeholders proactively
As soon as the stakeholders are identified, it is necessary to reach out to them. This part requires quite some diplomacy in the way you present yourself to avoid unnecessary pain in the following steps. Remind them of the reason for your work as well as what it’s in it for them. Again, the power/influence grid helps defining the communication patterns.
3 – Define scope
This should be defined with the sponsor prior to the workshops and could evolve throughout the modelling. Whatever the scope, two elements are important to keep in mind:
- The larger the scope, the more complex it becomes.
- If you analyze several similar processes, they should stay coherent in their scope (ex: if you describe processes end-to-end for 2 different products or services, the processes should have the same names (ordering, fulfilling, support, invoicing, etc.)
4 – Plan workshops / shadowing sessions
The next step is planning the different workshops to capture the process. A step further would be to shadow the (willing) stakeholders to make sure that you capture the actual process/way of working, and not their description of it. If you need input from more than 3 persons, it’s better to break the workshop group into smaller sessions.
5 – Define a Problem statement:
This could be done either prior to workshops or during, but it should be clear before why the process is necessary, what value its execution brings. If it doesn’t bring value (I.e. improve on a problem) then there is an issue with the process itself.
Step 2: Process Modeling
1 – Capture the AS-IS
The first step of modeling a process is to capture the current situation, not the ideal. This will allow to create a gap analysis for future improvement. The central question to ask stakeholders is then “what are you doing now?”.
2 – Work on the TO-BE
As stated, process improvements won’t be covered here. However, there are already some attention points when modeling what is currently done that will benefit the To Be model later.
Nomenclature:
Make sure that the words used in the process are coherent between all charts. If different stakeholders use various naming for the same task/element, it is your responsibility to create a common understanding. Concretely, it means that you should cocreate and validate a nomenclature together with all of them. Definitions could also be added to the document, but a process is ideally self-explanatory.
Flow of information
(what’s mandatory): If information flows through the chart, especially if it is essential to the process, then it should be clearly noted what information is transmitted by what medium. For example, a support ticket opened by a client creates a ticket number. It should be clear on how this number reaches the support team.
Connect the human chain with dynamic work design*
this is a concept developed by a teacher at MIT to increase process efficiency. I won’t go into the details, as it tackles process improvement, however the second principle “Connect the human chain through triggers and checks” clarifies the different steps. Each box in your process should have a clear trigger, even if it is a timeframe (ex: check the order after 72 hours).
Clear trigger and outcome
As stated in the previous point, the start of the process must have a clear trigger. It should answer “why is this workflow starting?”. Define the outcome that answers the problem statement outlined in preparation phase. It doesn’t have to be complex, for example, at a coffee shop: Problem: a client wants a coffee; Trigger: he asks the waiter for a coffee; Outcome: he gets a coffee.
Transparent responsibilities
Swim lanes helps visualizing who is responsible for each step. However, I’ve experienced each process should also have an overall owner. The process owner is responsible for the efficiency of the process, but not for assuring that the process is actually followed. In some cases, you could even divide the Ownhership? into two: a person accountable (typically a manager) and a person responsible (for example a salesperson making sure that the order is properly processed for his customer).
Reports
On a side note, communication is primordial while doing this. By using the power/influence grid, define a mailing list of stakeholders that should be kept informed. A mail is a good start. It should include:
- the change(s) made during a specific period
- the tasks ongoing/to do/not done
- the next steps
- any blocking point or question.
Ideally if someone else needs to do something, identifying them by name creates accountability as the email is public. Use reports to keep everyone informed and document your deliverables. Most importantly, it updates stakeholders on how the project evolves and what’s the “common knowledge” about it. Your stakeholders will discover misunderstandings between them as soon as possible in your project. 😊
Validation and next steps
Let’s say that you have a clearly modeled process, and that every involved stakeholder gave their input. The following steps vary a lot depending on the organization. Depending on their maturity in process Governance, organizations can have:
- repositories or libraries for processes,
- document that incorporates those processes,
- nothing set-up yet.
So how can you make sure that the process is known and understood by everyone?
Explicit validation
Providing information for a process can be a tedious task for some stakeholders. It can also get quite complex at some points. This means that it’s not uncommon to have an error in there. The best way to get the necessary feedback is to organize a formal process review with everyone. You lead the meeting by going through every step and highlighting the elements that could be subject to debate. Once done, send a meeting review with the process, stating that without any more comments in a given period of time, the process is considered validated. N.B: some organization have other type of validation process, but this usually complement other type of validation gate.
Follow-up
As explained regarding responsibilities, the follow-up should be done operationally by someone else. However, it is the responsibility of the process analyst to make sure that the process is optimal. After a given period, check that the process works properly. The preparation is like a new process (although shorter) and a review should point out to any deficiency in the expected outcome, delay, or cost. If the variance is too high or the outcome wrong, then dive into process improvement technics.
Top-down follow-up
This last point joins the previous one, as a process is (mostly) followed by people. Thus, there might be some change in behavior involved if the current process isn’t optimal. Management must be a real sponsor when it comes to change and improvements. It is their responsibility to make sure that the culture of change exists. As this aspect is often a huge undertaking, feel free to contact Steep to discuss how we can help to prepare an organization to potential change.
Conclusion
In this short article, I tried to cover what I think are the most crucial elements when capturing a process. Each of them could be explored further in its own right but I hope that you have a better understanding as a consultant or as a client on what is required of you to make sure that your process modeling is successful.
As stated, feel free to contact us if you face challenges regarding process analysis!
*source : https://mitsloan.mit.edu/ideas-made-to-matter/4-principles-dynamic-work-design
