Wednesday, July 19, 2017

Why do you have processes?

“Why do you have processes?”
“To model them”

This conversation really happened. It made me sad.

But it was also 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.



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

Every organization has processes. Whether or not they are performing well, they are 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 a focus on the “Deliver pizza” process.

What’s the concrete result of this process? You can, for example, find it out by answering questions like:
  • What's the reason a customer asks the pizzeria to execute this process? 
  • What does the customer want to pay for?

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

Just like the process “Grant permission” delivers (in the positive variant) “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, 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!




Thursday, May 18, 2017

Simple isn’t always that simple

What problems of your customers are solved because you execute your processes?
That’s my main question when I help organizations with improving “managing by process”.
In the end, a process is just a means. A means to deliver a result which hopefully solves the problems of your (future) customers.
By keeping the focus on that problem to be solved, I hope to prevent working on useless processes.  
And it helps you to put process improvement ideas in the “does it help to improve the process result?” context
But, as there are more roads that lead to Rome. also a process result can be reached in more possible ways.
And sometimes that might lead to complex solutions, Solutions that work, but could also have been simpler.
My experience is that, when you look to a problem with a certain experience and knowledge, it is sometimes hard to see other ways. Other ways that might be far less complex.  Do you recognize that?
That’s why I love processes; they combine people with different knowledge and skills. All with their own “simple” solutions.
To impress, I also like to say that I prefer simple solutions.  But suddenly I had to think about a funny situation from the time I was still at school.
In some way I ended up at  pre-university education (not sure if this is translated well from Dutch). That’s where I learned all kind of theoretical stuff. But in the mean time I was quite jealous of my friends.
Most of them were at schools where you learn practical things like woodworking, welding or repairing cars.  So, after quickly finishing my homework, I spent most of my times in sheds to, for example, working on mopeds.  
At one time Mountain bikes were the new hype.. And I and my friends all owned one. We thought it would be cool to know who was the fastest, so we all had bought a digital speedometer. You know, with a little magnet in the wheel.
To configure that speedometer well, you had to enter the circumference of the wheel. And me, as the smart guy from pre-university education, had learned a formula for that: 2πr
So I grabbed a measuring tape and tried to measure the radius of my wheel, Which wasn’t so easy for a bike without a kickstand. And with an all-terrain tire, what is actually the radius?
But finally I could use my fancy calculator and was able to calculate the circumference.  I proudly asked my friends “Shall I do it for your bike, too?”
“No” said my friend Jeroen. “But please throw me that measuring tape”
After that he picks up his bike, moves the wheel until the air valve is at the bottom. Then he draws a little line on the street, moves the bike till the air valve is at the bottom again and draws another line.
Then he puts his bike aside and measures the distance between the 2 lines. 
“You with your pi nonsense. Come on, grab your bike and let’s head for the woods”


Thursday, March 2, 2017

Lazy people, those process consultants



In the last 20 years I did quite some activities that could be labeled "something with processes".

I guess it won't surprise you that a big part of this time was spent on helping organizations that wanted to improve their processes. 
And those were all kind of organizations. There were the "usual suspects" like city councils, banks and insurance companies.  Also more exotic ones like power plants and a manufacturer of satellites and fighter jets.

And luckily I was also asked to contribute to companies that really matter. In industries like healthcare and education. 
Talking about education; I definitely have learned a lot in all those years. But for sure I don't know all the ins and outs of what is happening in the processes of those organizations.

And that is a hard time for a person like me. A guy who is very curious and who likes to know it all.

I want to know how things work. And, sometimes a little annoying, how they can be done better.

The biggest lesson I learned is that knowing all is just not possible as a process consultant.

Now I'm a little older, I think it's even better to not know it all. 
Every organization has processes on which the principles of "managing by process" are applicable, but I think "changing the processes" should not be the role of a process consultant.

And to be honest, wouldn't it be weird that I came to tell how to build a satellite or how to treat a patient?

(Luckily I got my own semi-professional hobbies were I am the owner and executor of the processes ;-)
The organizations that ask me for help, know very well what they are doing.  They might have lost a little grip on their processes and are looking for some help to get that back. With the final goal to spend more time on the real work again.

I see my role as a process-psychologist, asking open door questions like "What do you think yourself?"

A little kidding of course. Although, not completely. I believe organizations should improve their own processes. I can coach them a little or ask some mean questions to keep things in a proper (process)context.

But changing things? They should do that themselves. 
So I can take a nap.

Happy processing!