How to design an efficient process
First of all, don’t underestimate yourself – even the world’s smallest company has processes. Whether you’re manufacturing a product or providing a service, you run at least one process (even if you don’t realise it).
They can be disorganized, unstable, implied or 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 of good execution is knowing how to make those processes more organized and efficient.
Many people get confused and end up dealing with processes as if they were projects. Due to that mindset, they choose all the wrong metrics, tools and approach to deal with them.
Let’s start off by pointing out the main differences between projects and processes:
Projects are finite: They have a beginning, middle and end. Projects are events such as building a house, launching a new project, 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, making pizzas…after you do the same thing 100 times, you’re expected to be pretty good at it. It was according to that philosophy that Toyota got as close as possible to perfection in terms of execution.
How does a process work?
In theory, a process means a series of sequential steps used by a person or a team to get to a desired result. In real life, there are many different approaches to represent how a process works.
BPMN and Flowcharts (aka the management terrorists)
The most widely known approach to processes is workflow designing (flowchart/diagram) according to the BPMN methodology. Check out this example:
In my honest opinion, I consider this approach a crime against process management. I’m not against the methodology but I can safely say that it’s one of the main reasons people hate process management.
It’s too complex for most members of any operational team. Asking an average “normal” person to draw a process using a flowchart or BPMN notation is the same as asking someone who’s not an architect to create a house project on Autocad or asking a 10 year old to drive your car down the street.
I could bet over 90% of those charts end up in a thrash can or abandoned 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 individually create a flowchart of the process they’re involved in it’s guaranteed they’d all be different. All of them, no exceptions.
So, how can you represent your process?
I’m particularly fond of a simplified approach, based on the SIPOC methodology. The acronym stands for Suppliers, Inputs, Process, Outputs and Customers.
Here’s a very simple example of a process mapped according to SIPOC:
You can simplify it even further taking the S and the C out of the picture and call it IPO.
How to map your process using a simplified and intuitive approach?
Let’s exemplify things in an easier and more didactic way. We’ll use a real life example of a common process in which you’ve been the output and maybe have been (or will be) an input. We’re talking about the oldest process in the world:
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 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 bigger chance of achieving the expected end result.
If you feel the need to be more specific in order to ensure the process’ execution, stick to this easy to understand and memorize approach. For example:
As I’m sure you’ve realised, I’m using the simplest examples I can think of but this approach works for more complex situations such as business processes. The complexity of the processes actually makes it a lot more interesting!
Let’s take a look at how a sales process works on a CRM system:
Jokes aside, you now have two challenges: how to represent your process keeping things simple and how to ensure your team will actually follow it.
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 you need to set off your 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.
For example, let’s see what happens when someone reports a bug:
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 consequences in this scenario:
- The technical team doesn’t prioritize this bug (due to the lack of information) and takes a lot of time to solve it;
- The responsible development spends a lot more time than necessary trying to find the bug and/or replicate the scenario where it happens;
- The technical team stops working at an important and complex feature to fix a cosmetic, low priority bug;
- 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?
Another example: Creating a lead for the sales team
Revenge time! 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.
2. Process and execution steps
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 with customer support I can say for sure that the time to respond to the most critical requests (critical due to their severity or because they come from important customers) is the most important performance indicator.
Here’s an example of instructions on the screening phase of a customer helpdesk process:
If you work at HR, more specifically recruitment, the information you gather about a candidate is essential to make informed decisions. Therefore, having a checklist with all the essential questions to ask might be an interest idea to remind the interviewer during the interview.
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 last (but not less important) part of this series: How to measure your process.
Organize and measure your process with Pipefy!
Pipefy is an intuitive, simple to use, process management software. It allow businesses of all sizes to run the entire company’s processes in a single platform, ensuring efficiency and solid execution.
Pipefy offers a great variety of pre-designed process templates to provide a base for you to design your own processes.
Its entirely flexible and customizable structure allows you to adapt Pipefy to your needs. It also offers tools to help automate, integrate and measure your processes.