Why do you have processes?

“Why do you have processes?”

“To model them”

This conversation really happened during a workshop. It made me sad.

That made it a trigger to spend, in all my assignments, some more time on explaining the terms process results and goals.  Which to me are the essences of a process.

Goal, results, process….what are you talking about?

Process results and process goals. I often talk/tweet about them.

To me they are two naturally separated aspects of a process. Sometimes that raises questions. That’s the reason why I spend some words in this blog to explain what I mean.

Maybe the confusion comes from the fact that different words are used for the same things, which is quite common in Process country.

If that’s the case, then we’ll know that and solves the confusion. hopefully. 

First of all; processes are a means, not a goal

Every organization has processes. Whether or not they are performing well, they're just there.

Processes are the means to deliver products or services that (hopefully) solve the problem(s) of customers.

And that brings me to what I call the process result; the “tangible” result of a process.

Process results

Like in many of my stories, I will use the simple example of a pizzeria, with focus on the “Deliver pizza” process.

What’s the concrete result of this process? You can, for example, find out by answering questions like:

• What's the reason a customer asks the pizzeria to execute this process? 
• What's 'the thing' the customer wants to pay for?

And indeed,in this case that’s “a delivered pizza”. That’s what I call the tangible process result.

Just like the process “Grant permission” delivers (in the positive flow) “a granted permission” and the process “Hire new employee” has “a hired employee” as process result.

Not that concrete for every process

It’s not always so straightforward as in the pizza example, because you will find different types of processes in Process country. Not for every type of process a concrete result can be defined so easily.

Some processes just start with a problem to be solved, like (in healthcare) “I have been suffering from headaches for 3 weeks now”.

There are also processes where the result is defined at the start of a case. For example, when someone wants to let build something very customized.

In those processes, “Defining the desired process result” probably will be one of the first steps.

A good process starts at the end

Looking back to the first paragraphs of this article, I realize I started from the wrong end in the Pizza example. I said that a process is a means to deliver a result. So, that desired result should have been my start.

What problem does the process result solve?

From a more strategic point of view, it might be a good idea to start to understand what really makes customers happy. Then it’s often needed to look beyond the concrete process result and try to get clear what problems you want to solve for your customers.

In the example of the pizzeria that could be something like “Customer is hungry, doesn’t want to leave the house and is not able or willing to cook”.

A “delivered pizza” can solve this problem.  And the pizzeria collected and combined all the resources to execute a process that delivers this result.

That’s why I like to start at the end. To determine why a process result is really needed. This also prevents me from spending time at “useless” processes.

Useless processes?

“Pizza baked” sounds quite resultish, but it’s not the result customers call (and pay) the pizzeria for. It’s an in-between product/milestone to finally get to the “pizza delivered” result.

The advantage of thinking about the process result is that you don’t spend time on “vague processes”; processes of which nobody can tell what problem they solve.

But, the customer is hungry, so let’s get back to the “Delivered pizza” result.

There are millions of pizzerias (even in my small town there are 7) that deliver the same process result. Why is it that some pizzerias attract different customers than other pizzerias? Why are they all able to earn a living?

I think that’s caused by how customers expect a process to perform. And that brings me to what I call the process goal; the promise about the process result.

Goal; promises about the process result

As said, a process is a means to deliver a result.

To be able to design that process, you have to be clear on what you promise about that result; the process goals. And that can be more than one promise.  

For customers:

•  “Pizza delivered” within 35 minutes

Or more promises:

•  “Pizza delivered” within 35 minutes and warmer than 70 degrees.

Or very ambitious:

•  “Pizza delivered” within 35 minutes, warmer than 70 degrees, tasty and never more expensive than 10 Euros.

So, the process goal is what you promise about the process result. This can be a promise based on time, costs or quality.

This combination of process result and connected goals, define how the world sees your pizzeria. Fast? Cheap? Tastiest in town?   

Process goals are dependent on “who you want to be”

What you promise about a process result is depending on how you want customers see your organization. In fancy books this is probably called something like vision, strategy or proposition.

In Pizzaworld, you’ll see differences, of course. The big chains that might aim for “fast and standardized” and the more traditional pizzerias that want to offer “quality and a taste sensation”.  Although “tasty” is in the eye of the beholder.

Proposition has influence on process design

A proposition has its effect on what you promise about a delivered pizza. So also on the design (and hopefully execution) of the process.

In situation 1 (fast and standardized) delivering pizza is turned into an efficient production line process, where every executor has a little standardized task in the process. This serves the goal of creating a pizza that always has the same size and taste and will be delivered in a predictable time!

In the second situation it might be possible that the owner of the restaurant will execute all the steps in the process by herself and will put all her experience and love in the pizza.  This will probably take more time and might be more expensive.  But that’s what customers of these types of pizzerias are willing to accept.

If life was that easy...

In everything I wrote so far about process result and goal, I made one big assumption: the paying customer is the only stakeholder of the “deliver pizza” process.

In a Process Fairy Tale this might be true. And yes, solving a problem for a customer should be the main focus of a process. But, if you only do things that “add value” for the customer, you might end up in jail or go bankrupt.

Because, sticking to the law and sending invoices; does that add value for the customer?

So be aware that the customer is not the only stakeholder of a process.

More stakeholders

For sure, without a pizza eating customer, the “Deliver pizza” process isn’t needed at all.  But in the context of making clear the process goals, it’s always good to acknowledge there could be more stakeholders of a process.

Think about the Pizzeria’s owners that want a margin of more than 40% on each delivered pizza.

Or some kind of government agency that is responsible for food safety can have some hygiene requirements for the process.

In that case making a process “Lean” isn’t an easy task. Because when designing a process you have to take all these above requirements and goals into consideration.

Think about an extra step to measure the temperature of the pizza. Or a process rule that states that a delivery car is not allowed to carry less than 4 pizzas to prevent that the margin gets too low.

It’s these kinds of things that make a process feel “unleaner”

Process result and – goals; should I really care?

All the above is not that shocking. Luckily. But, is it important?

What is important? There are more important things in life, but in the context of process management I think it matters. Because executing processes that solve nobody’s problem is fooling yourself.  It helps me to get a clear view on the reasons to design a process for. And execute, of course.

And that assures me that I do something to help others with useful process results.

Besides that; I think a shared (process) goal is a minimal prerequisite to collaborate on cases in a process.

And of course, when you are a one-man-business, you probably do the whole process on your own. You are very clear about your process results and –goals and it’s probably communicated well with your customers.

But when talking about processes in which different players contribute to the process result, I think making clear the process result and -goal is the least you can do for all of the stakeholders.

Make it clear!

And let’s make that the conclusion of this story. Processes have a result with goals attached to that.

Or better; you promise something to your customer and like to design and execute your processes in such a way you can deliver that promise.

So, I prefer making those process results and goals very clear. So that everyone is aware and can contribute to a better process design.

And yes, when you make something clear it’s possible someone will not like it.

But there’s probably a fitting process result for everyone ;-)

I wish you useful processes!