Every single person and company in the world use processes. They are all around us.
Whether you’re completing part of your personal daily routine, manufacturing a product, or providing a service, you run at least one process (even if you don’t realize it).
Your processes might be disorganized, unstable, or implied. They may even exist only inside people’s heads, but they’re there. You may not know how to describe them but, deep down, they exist. The secret to succeeding in business is knowing how to make those processes more organized and efficient.
In this post, we lay out a simple model for visualizing and designing any type of process, and walk through some examples to illustrate how it works.
Buyer’s Guide to Automation PlatformsDownload now
Process vs. project
To begin, let’s talk about the difference between a process and a project.
Sometimes people mistake a project for a process. As a result, they choose the wrong metrics, tools and strategies for managing and optimizing them. Being able to tell the difference between a process vs project is critical if you want to make your process more efficient. Here’s what you need to know:
- Projects are finite: they have a beginning, middle and end. Examples of projects include events such as building a house or throwing a party. Projects are unique and must come to an end at some point.
- Processes are continuous: they’re cycles, happening over and over again. Once you get to the end you go back to the beginning and start it all over again. Also, the more you execute it, the more you learn about it and improve it. Think about manufacturing cars, importing merchandise, or making pizzas…after you do the same thing 100 times, you’re expected to be pretty good at it.
So now that we know how to identify a process, let’s take a closer look and how to design them.
How do we illustrate a process?
A process refers to a series of sequential steps used by a person or a team to produce a desired result. That’s a solid definition, but what if we want to visualize a process? There are a couple of different ways we can illustrate how a process works.
BPMN and flowcharts
I’m not a big fan of BPMN because I think it’s too complex for most members of any operational team. Asking an average person to draw a process using flowchart symbols or BPMN notation is the same as asking someone who’s not an architect to create a house project with Autocad. It’s just not practical.
I’d bet that over 90% of those charts end up in the trash or at the bottom of a drawer. No one but the flowchart creator can understand it. They’re not intuitive, practical or instructive. They’re definitely not suitable to manage daily operations.
If we did a quick experiment and asked different members of a team to each create a flowchart of the same process, every one of them would create something different. All of them: no exceptions.
Low-code Automation: Good for Business, Great for ITRead the Report
I’m particularly fond of a simplified approach, based on the SIPOC methodology. The acronym stands for Suppliers, Inputs, Process, Outputs and Customers. Let’s look at an example of how SIPOC can be used to visualize a process many of us will recognize:
Voilá! It’s as simple as that! If people didn’t insist on complicating things by drawing a giant map with a tangle of lines and arrows that resembles a treasure map (or a spaghetti bowl!) the problem would be solved.
The I-P-O Method
The simpler and more intuitive the representation of a process is, the bigger the possibility of people understanding it and, consequently, executing it more efficiently with a better chance of achieving the expected end result. One way to simplify the SIPOC method even further is to remove the S and C and just focus on I-P-O.
For example, let’s take a look at how a sales process works on a CRM system:
These three elements (input, process execution and output) will be the starting point to guide your team’s execution. Now, let’s see how each part of this representation works.
The input represents all the elements needed to trigger the process. Raw materials, equipments, infra-structure, people, etc. If you work at a tech company, for example, all your inputs will likely be information. In this case, the better the information you have access to, the bigger is your capacity of solving the situation efficiently.
Example: IT bug tracking
Think about the following situation: A salesperson found a bug and created a demand directly on the development team’s backlog. He described it as “there’s a bug on the sign up, it isn’t working in some situations.” No wonder developers hold grudges against the sales and customer service teams.
Bad input leads to bad execution. Here are a few of the possible outcomes in this scenario:
|1||The technical team doesn’t prioritize this bug (due to the lack of information) and takes a lot of time to solve it.|
|2||The responsible development spends a lot more time than necessary trying to find the bug and/or replicate the scenario where it happens.|
|3||The technical team stops working at an important and complex feature to fix a cosmetic, low priority bug.|
|4||The technical team stops working at a feature that would impact 100% of the users to solve a bug that only impacts 5% of them.|
To improve this process’ quality and speed of execution you need to start improving the input quality. What if this company had a structured process to create bug reports? A simple form in which the team had to answer the following questions:
- What’s the bug?
- Where does the bug happen?
- In which situations does the bug happen?
- How many people are affected by it?
- How severe/priority is it? Is it a blocker or a cosmetic bug?
Example: Creating a lead for the sales team
Consider this situation: one of the developers meets a colleague from the sales team in the hallway and tells him “My cousin is interested in our product. He said we should schedule a meeting. I’ve sent you his email just now”.
Again: bad input, bad execution. Here are the possible consequences:
- The salesperson doesn’t give proper attention to the lead and fails to realise that the cousin was the CEO of a Fortune Top 500 companies;
- The salesperson spends a lot of time trying to figure out the cousin’s information searching on google, linked’in, etc.
- The salesperson contacts the cousin using the standard selling pitch and doesn’t attract enough attention to move forward with the sale.
To improve this process’ quality and speed of execution we’ll go back to the input quality. What if this company had a structured process for people to add new leads asking the following questions:
- What’s the contact’s name?
- What company does he/she works at?
- What’s his/her position?
- Email and phone number
- How many employees does the company have?
- What does he/she need?
No wonder that most of B2B software solution companies ask for a lot more information than just the email when capturing a lead.
Another simple example of process improvements is the good old expense reimbursement process. What would otherwise be poorly managed on email threads can be a lot more organized, didactic and intuitive.
How to define your process inputs
In order to define a process’ inputs I strongly recommend you explore the knowledge of the person or people in charge of executing it. Ask them “What do you need to start the process? What else you could have to make the job easier? What would save time?”.
Important: Don’t demand excessive information or data that doesn’t add any real value to the business or to the person executing the activity.
Mix all the ingredients, prepare, bake and serve. The execution steps are much like a recipe for a cake with all the steps you should follow to make sure you’ll make a great cake.
You can never have too much details – as long as they’re relevant. The more detailed the information, the bigger the chances of going through the whole process without mistakes, delays or waste of ingredients.
How detailed should each instruction be?
The level of detail of each step should take three things into consideration:
- Level of experience of the person/people executing the activity.
- Impact on the final result (quality, time and cost wise).
- Amount of risk involved.
In the cooking example perhaps you shouldn’t need to inform a sous chef about how he should turn the oven on or separate egg whites from the yolks. However, when talking about the preparation of a specific dish it would probably be wise to inform the exact cooking temperature and time it should stay in the oven.
During this step of the process it might also be necessary that he takes note of the amount of each ingredient used for posterior inventory control.
The level of instruction should vary according to how experienced are the people executing the task. I remember to this day of a hostel in San Francisco I stayed at in which guests would cook their own meals. The whole kitchen had yellow posters with basic instructions, such as: how to turn on the oven, step-by-step instructions on how to cook a pancake, how to throw out the trash, etc.
Tips to help map the execution steps:
Investigate your failure history: If you’ve faced recurring problems with the execution of a certain step of your process, that’s a clear sign that tells you to probably add more details regarding the step’s execution.
Analyse how each step impacts the end result: Find out which variables can affect the quality of your process’ result. If a certain variable causes a big impact it’s probably worth adding specific instructions for the execution of this step.
There’s no special training needed for sales clerks at a shopping mall store to know which temperature they should leave the AC on in order to have a pleasant temperature. There’s even less need to create a procedure for verifying the temperature hourly. However, if you work at a meatpacking industry, this small routine can save your business from a huge loss.
If you work in sales, having a structured and consistent sales pipeline process makes a huge difference in customer experience, as well as the volume and quality of leads you can follow up on. Here’s an example of what a sales pipeline process looks like using low-code automation software:
The output is the expected result after executing a process. If a team doesn’t have a clear idea of what’s the expected output of their activity, there’s no way for them to analyse whether they’re performing well.
There’s actually many, many people that just focus on executing their activities without even knowing why they’re doing them. Another common error is that, when managers take the time to describe the process they supply a lot of details about the activity but end up neglecting to inform what’s the expected output.
The expected output should be clear when it comes to three aspects:
- Delivery time
When these elements about the output aren’t defined and spread around the team, mistakes and inefficiency start to happen:
- In a restaurant, dishes are served cold or not on the right cooking point, making customers unhappy
- A designer that delivers material with amazing quality 2 weeks after the due date he informed its customer
- Production lines wasting raw material
- Airline employees that don’t handle the passengers luggage with care after the plane lands
- Contractors that deliver the service but leave behind a dirty construction site
- Customer helpdesk channels that end up solving the customer’s problem only after a long time waiting and treating the customer with a rude attitude
- Employees that spend extra hours on a project to reach a result that the customer doesn’t realize exist or doesn’t value
- Salespeople that take too long to send out a proposal and lose the sale’s timing
- Services that end up generating a lot more cost for the supplier due to rework or misalignment with the customer’s expectations
In the restaurant’s case the expectations about the dish were clear: it should be served at the right temperature, seasoning and cooking point. It should be delivered within X minutes and have the right amount of food.
A salesperson should work towards achieving its sales goals. However, he/she should do that selling in a specific market/region, offering discounts within their margin and promising a viable delivery date for both the customer and the supplier.
A helpdesk attendent should answer within two hours of the customer’s request, always respecting the company’s tone of voice and being helpful. Most of all, he/she must do whatever is within their power to solve the customer’s problem.
If a plumber is hired to fix a couple of pipes, he’s expeted to deliver the service within X hours with similar finish to the original state. After finishing his work, he’s expected to clean the site without leaving behind paint or cement residue.
When you make the result expectations of the activity really clear you’ll actually go to less trouble explaining each activity step by step while improving the service’s quality.
Important tip: focus on what is instead of what it should be
Managers tend to map processes the way they wish they could be instead of how they really are. Don’t make that mistake. It doesn’t matter whether a process is simple and still isn’t perfect in your point of view. The existing process is what you’ll map and start monitoring, even though you don’t consider it to be perfect.
Only after the process is well established and all team members have adapted to it without resistency you’ll start proposing ways to improve it. If you do that you’ll have the advantage of having real data to compare before and after results.
Stay tuned for the final installment in this series: how to measure your process.